Privacy
What Semantix stores, what it doesn't, what each of the three switches actually controls, and what genuinely leaves your machine.
Settings → Privacy. Three switches and one number, and a clear picture of what they do is
worth more than the switches themselves. Start with the picture.
Where your data actually is#
The editor half of Semantix works with no network at all. The index, search, the code graph, your files and your settings are on your own computer. The word server on this page means one of two things, and it matters which: the on-device Semantix server that runs the index and the agent for you, or the Semantix account service you signed in to.
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 on the Models page, 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.
Then there's your account. Signing in involves your email and password, and a signed-in Studio checks in with the account service when it starts. Three things are kept against your account rather than on your machine, and every one of them is off until you turn it on: conversation backups, memory, and — under the Task Manager — your scheduled tasks and their run history.
Three smaller ones worth knowing:
- A remote MCP server you connect receives whatever the model sends it.
- A custom tool or task you build can call any URL you configure, on your behalf.
- Semantix's own models — the seats on the Studio page — send your conversations to that provider whenever memory does its background work.
This machine: Local only#
The first switch, on by default, in its own section.
What it does: stops your work from being kept in the server's database. With it on, your runs, per-run token accounting and memory captures aren't written there, and nothing is backed up to the cloud. Turns still reach your model provider — that's the one thing no setting here can switch off.
What it doesn't do — worth spelling out, because "local only" sounds absolute:
- Your messages still go to the on-device agent server on every turn — that's how the agent runs at all — and from there out to your model provider exactly as always.
- 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.
While Local only is on, everything in the second section is disabled. Turning it on while
backups already exist on the server asks, right there on the page: You have cloud backups on the
server. Delete them now? — with Delete all my backups (N), This project only (N) and Keep.
That's the only clean-up any switch here offers, and it's offered at the last moment the server is
still reachable.
When sharing is allowed#
The second section, headed Off while Local only is on.
Back up conversations#
Off by default. With it on, a copy of each conversation is kept on the server so it follows you across machines. 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.
Two icon buttons sit beside the switch. Upload existing conversations to cloud sends this
project's saved conversations up (anything mid-stream is skipped and goes when it settles).
Restore conversations from cloud brings this project's copies back down. Each reports on the row
as it works — Uploading… 12/40, Backed up 40 of 40., Nothing to restore for this project.
Turning the switch 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 buttons don't consult the switch. They run whenever Local only is off, whether or not backup is enabled.
Semantix Memory#
Off by default. This is the switch behind the agent remembering you between conversations — the one gate, and the whole gate. With it on, every memory reflex runs on every message and the memory tools are declared to the model. With it off, the memory organ is never spoken to and every conversation starts from nothing.
It does two things, and it's worth separating them.
It keeps what's worth keeping. After a turn, a background pass on your Primary seat model reads the conversation and files durable facts into memory. Those captures are stored on the server, against your account.
It opens recall. As you type, the agent draws on what it already knows, and can be asked to remember or forget something deliberately.
→ Memory — what it remembers, and what it doesn't
Important
Memory is not stored on your computer. Unlike your conversations, your index and your settings files, what the agent 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. To erase it, use Clear memory on an agent's row in the Project Manager, or Forget project — both are there, not here.
→ What's stored, and how to delete it
Note
Memory needs a model of its own to do its filing. That's the Primary seat on the Studio page, and it's empty until you set it. With the switch on and no seat, the walker refuses each turn and says so once per conversation in the transcript.
Walk memory every#
A number, nested under Semantix Memory: how many of your turns pass between visits from the memory walker. 1 by default, up to 50. It's a pace, not a consent — so, unlike the three switches above, it's remembered per project, not against your account.
Where these settings live#
The three switches 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. If it can't reach the server at all, the page says so at the top — Couldn't load your saved settings — showing the privacy-safe defaults — and a change that fails to save says this choice won't stick after a reload. In both cases the choice is live on this device right now; it just hasn't reached your account.
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-id>/checkpoints/ |
| Provider connections, including API keys | ~/.semantix/USER/providers.json |
| Custom models, including API keys | ~/.semantix/USER/custom-models.json |
| MCP servers, including auth headers | ~/.semantix/USER/mcp-servers.json |
| Instructions, slash commands and custom tools | ~/.semantix/USER/ and per project under WORKSPACE/ |
| Sign-in credentials | ~/.semantix/USER/credentials.json |
| Claude Code usage statistics | ~/.semantix/analytics.db |
| The code index | ~/.semantix/WORKSPACE/<project-id>/index/ |
What isn't in that table: what the agent remembers, your conversation backups, and your tasks.
Those 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.
Two of the rows deserve a sentence each.
Workspace snapshots are the largest copy Semantix makes of your code. Before the agent's first approved change in a run, your workspace 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.