Privacy

What Semantix stores, what it doesn't, what each of the four switches actually controls, and what genuinely leaves your machine.

Four switches, and a clear picture of what they do is worth more than the switches themselves. Start with the picture.

Where your data actually is#

Studio itself doesn't contact anything remote. Every address the app uses is on your own computer: the indexer, the agent server, the task daemon. The word server in this tab means a program running on your machine, and the backups it calls "cloud" are stored by that local program. Fonts are bundled, no page loads a remote asset, and there's no update check.

Nothing is reported to us. No analytics service, no crash reporting, no third-party scripts. Semantix does track your token use and cost — for you, on your machine, in the Stats view — and none of it is sent anywhere.

What genuinely leaves your machine is the model call, and it's the reason you're using the app. When you send a message, your prompt, the conversation so far, and whatever code the agent reads or writes go to whichever model provider you're using — Anthropic for Claude, or whatever endpoint you configured in the Models tab, with that provider's key.

There's no switch for that anywhere, and there couldn't be: it is the product. Choose your provider accordingly.

Three smaller ones worth knowing:

  • A remote MCP server you connect receives whatever the model sends it.
  • Signing in involves your email and password.
  • Automations you build can call any URL you configure — the task daemon runs those steps, so an automation reaches out on your behalf even though the daemon itself is local.

Local only#

The first switch, on by default.

What it does: stops the agent server from keeping a record of your work. With it on, your runs, per-run token accounting and memory captures aren't written to the agent server's database, automatic cloud backup is off, and your project id isn't attached to requests.

What it doesn't do — worth spelling out, because "local only" sounds absolute:

  • Your messages and history are still sent to the local agent server on every turn — that's how the agent runs at all, and from there the turn goes out to your model provider exactly as it always does.
  • Your workspace's path is still registered when the app starts.
  • Your conversations are still saved to a local database on disk. That's the local-first store that makes them survive a restart, not a record kept about you — but it exists either way.
  • A log of every tool call is still written on turns that run on the agent server: which files were read and written, what was written to them, which shell commands ran and what they printed.

Everything in that list stays on your own machine except the model call itself, which Local only doesn't govern and no switch here does.

Note

The tool-call log applies to turns on your own configured models. Claude Code turns run through the on-device sidecar instead and write none of it — no tool log, no memory capture, no project id.

Turning Local only back on offers to delete conversation backups already on the server — all of them, or just this project's. That's the only clean-up any switch here offers; records already written stay written.

While Local only is on, the other three switches are disabled.

Back up conversations#

Off by default. With it on, a conversation is copied to the server shortly after it settles, so it survives losing the local database. Conversations are stored locally first and always; this is a copy, not the original.

Note

Turning it on uploads every conversation you currently have open, in full, within a couple of seconds — the whole prior transcript, not just what you send next. If that's not what you want, close what you don't want copied before enabling it.

The ⬆ button uploads this project's saved conversations (anything mid-stream is skipped and goes up when it settles). ⬇ restores this project's conversations from the server.

Turning it off stops future backups and leaves existing ones in place. Two ways to remove them: switch Local only on and accept the purge, or delete a conversation locally — which deletes its backup too, as long as Local only is off.

Note

The two arrow buttons don't consult this checkbox. They run whenever Local only is off, whether or not backup is enabled.

Semantic notebook#

Off by default. Gives the agent tools for keeping its own notes across conversations, scoped to the open project — it can write a note, search its notes, and list recent ones.

Off genuinely blocks them, twice over: the tools aren't described to the model at all, and the app refuses to run them even if a model asks for one anyway. Turning it on is what makes them exist.

The notes are kept off your machine, which is why Local only overrides this switch — with Local only on, the notebook stays closed no matter what this checkbox shows.

Semantix Memory#

Off by default. This is the switch behind the assistant remembering your project between conversations. It does two things, and it's worth separating them.

It stores completed exchanges. Your message and the assistant's reply are kept so Semantix can build memory over time. Three conditions, all required: the turn has to finish cleanly (a failed turn isn't captured), you have to be signed in, and it only applies to turns on your own configured models — Claude Code turns are never captured.

It opens recall in chat. With this on (and Local only off), the assistant can draw on what it already knows about this project as you type, and can be asked to remember something deliberately. With it off, that's all closed and every conversation starts from nothing.

This switch decides whether; Settings → General → Memory decides how much.

→ Memory

Important

Memory is not stored on your computer. Unlike your conversations, your index and your settings files, what the assistant remembers lives on the Semantix server, tied to your account, and travels with you to another machine. That is the point of it — and it is the reason Local only switches it off entirely.

Turning it off stops future capture and closes recall from the next message onward. What's already stored stays stored — there's no purge for it in the interface, so switching off is a way to stop adding, not a way to erase.

Where these settings live#

Unlike everything else in Settings, these four are stored against your account, not on this machine. Sign in somewhere else and your privacy choices follow you.

A copy is cached locally so the app can fail safe before it reaches the server.

Important

That cache isn't cleared when you sign out, and it doesn't just affect what the tab displays — it governs behaviour until the server's copy loads. On a shared computer, the next person's first turns run under the previous user's privacy posture. Don't rely on signing out to reset it.

What's on your disk#

What Where
Conversations, with their token usage ~/.semantix/conversations.db — one database for every project
Workspace snapshots ~/.semantix/WORKSPACE/<project>/checkpoints/
Custom models, including API keys ~/.semantix/USER/custom-models.json
MCP servers, including auth headers ~/.semantix/USER/mcp-servers.json
Instructions and slash commands ~/.semantix/USER/ and per project
Sign-in credentials ~/.semantix/USER/credentials.json
Claude Code usage statistics ~/.semantix/analytics.db
The code index ~/.semantix/WORKSPACE/<project>/index/

What isn't in that table: the notebook and what the assistant remembers. Both are kept on the server rather than in ~/.semantix/, so deleting local files won't remove them and a home-directory backup won't preserve them. Both are off by default and both are suppressed by Local only.

Two of the rows deserve a sentence each.

Workspace snapshots are the largest copy Semantix makes of your code. Before the agent's first change in a run, your entire workspace — not just the files it touches — is snapshotted so you can roll the run back. No privacy switch affects this. It's how Restore works.

The statistics database is built by reading Claude Code's own transcripts from ~/.claude/. It's derived, local, and never sent anywhere, but it does mean Studio reads that folder.

Keys and credentials are stored in plain text, readable only by your user account on Linux and macOS. A backup of your home directory carries them with it.

→ Where your keys are stored