Your data and traces
Your project stays local. W1 sends the context a request needs, never your whole codebase, and never asks you for a provider key.
What leaves your machine#
To answer a request, W1 sends the model the context that request needs: your message, the thread's carried context, and the file content or command output the actor has actually read in the course of the work.
What it does not send:
- Your whole codebase. Only what a step actually read.
- A provider API key. There isn't one. Model access is hosted by W1, so there is no key on your computer to leak.
- Your files, as files. Nothing is uploaded as a repository, a backup or an index.
The Privacy Policy is the legal statement of this. This page is the engineering one.
What stays on your machine#
| Stays local | Where |
|---|---|
| Your project | Wherever you keep it. W1 never copies it elsewhere. |
| Full run traces | ~/.w1/userdata/workspaces/<folder>-<id>/runs/ |
| Rewind snapshots | The same folder, under rewind/ |
| Memory | ~/.w1/userdata/memory/ and the project's own memory folder |
| Your session | ~/.w1/auth.json, permission-protected |
Traces#
A trace is the full record of one run: every step, the arguments, what came back, what changed, and the terminal state. It is written locally, and it is genuinely complete — which is what makes it useful when something goes wrong, and what makes it sensitive.
A trace can contain prompts, file paths, command strings, observations and project detail.
Do not attach a trace unless support asks for one.
If support does ask, open it and read it first. Remove anything private, and never send a trace from a project that contains secrets or client-confidential material. W1 support will never ask you for a provider key, and never needs one.
What W1 collects#
W1 records product telemetry so it can tell whether releases are getting better or worse. It is deliberately structural only: counts, states, timings, versions and error classes.
It does not include prompts, model output, file content, paths, command strings, your documents, or secrets. The rule is simple enough to check: if a field could carry a piece of your work, it is not collected.
The service status shown on the support page is reachability only — it exposes no providers, internal errors, traces or infrastructure detail.
Publishing an artifact#
artifact_publish is the one tool that deliberately puts something on the internet, and it is built so that publishing does not mean handing W1 your content:
- The page is encrypted on your machine. Only ciphertext is uploaded.
- The decryption key lives in the link's
#fragment— the part of a URL a browser never sends to a server. Whoever has the link can read the page; the server holding it cannot. - W1 asks you before it publishes, every time, and offers private or public. Declining is a normal answer, not an error.
Secrets#
The practical advice, in order of how much it will save you:
- Do not put secrets in a project folder you open with W1 — or any other tool. Use your platform's secret store.
- If a task genuinely needs a credential, give it the narrowest one that works, and rotate it afterwards.
- Review what a run did before you push it anywhere. Every file it touched is listed.
W1's own safety floor helps — it will not run curl … | sh, it will not escalate privilege, and it stays inside the project folder — but a gate is consent, not containment. See Permissions and access.