privacy
What happens to a trace you upload.
Last updated 2026-11-02
This page describes the service as it is built today, not as it is planned. There are two ways to use Boxdawn and they are not the same: a one-off upload, where you are not signed in and nothing about your trace is kept, and a connected project, where you are signed in and we keep measurements over time. Signing out is how you choose the first one. Where a section below applies to only one of them, it says so.
Optional account, no tracking
You can use Boxdawn without signing in, and that is the default. Signing in is optional, and it sets cookies whose names begin with sb-, which carry your session and nothing else. The site loads no analytics script and embeds no third-party tracker, so no other cookie is set. Our hosting providers keep their own standard request logs, as every web host does.
What happens to the file itself
An uploaded file is sent over HTTPS to the analyzer, written into a temporary directory, analyzed, and that directory is destroyed when the request ends. We do not copy it anywhere of our own, and we do not use it to train anything. On a one-off upload that is the whole story: the run happens inside that single request, and nothing about the file outlives it. A connected project is different. The run is handed to Modal as a background job so this page can poll for the result, and Modal keeps that job's result fetchable for up to seven days before it expires. The boxdawn submit command sends the file to that same hosted analyzer with a project key, so it takes the same background path. From boxdawn 0.5.21 it also sends the sub-agent trace files Claude Code wrote for that session, in the same request, and they are handled exactly as the session's own file is. On that path the file itself travels to Modal as the arguments of that job, and Modal's client puts arguments above a size threshold into its own blob storage rather than passing them inline. In the client we read, that is 2 MiB for any call at all and 8 KiB for a background call like ours. The platform can raise either, and for our own function it does not: we asked the service on 16 September 2026 and it sends no such override, so those two figures are what apply. How long Modal keeps that copy we do not know. The seven days above is documented for the job's result, we have found no published figure for the arguments, and we would rather write that down than guess.
Where the analysis runs
The hosted analyzer runs on Modal, a third-party serverless platform, so an uploaded trace leaves your machine. Modal routes uploads through its servers in Virginia, USA, which is its default region. We have not fixed the region the analysis itself runs in, so we do not promise a country here. Transfers out of the EU are covered by the standard contractual clauses in Modal's data processing addendum, which comes with its terms rather than being something we negotiated.
Where your account and measurements are kept
Accounts and measurements are stored in Supabase, in Seoul, and that one we do fix. The analysis happens elsewhere, and neither the trace nor the report is stored there; what is kept afterwards is kept in Korea. Korea is one of the countries the European Commission has recognised as providing adequate data protection, in a decision adopted on 17 December 2021, so personal data can move there from the EU on the same footing as a transfer inside it.
What could reach a model provider
The deterministic detectors do the analysis on our own machines. The semantic-duplicate LLM-judge is never enabled on the hosted analyzer, on any plan. One further layer is different: a verification check that asks a model whether a session confirmed what it changed. Our own API key is present on the hosted analyzer as of 3 September 2026, and on a paid project this check runs on every upload, automatically. It is on by default, and a project admin can switch it off for that project; while it is off this check never starts, so this check sends nothing from that project's traces to a model, and waste measurement keeps working as before. There is no request parameter that turns it off for a single upload, and a free project is refused before the call is made. The command line sends files with boxdawn submit. It sends the file to the same hosted analyzer with your project key, so the hosted rule above is the one that applies: on a paid project with the check on, it runs there, on our key, whether or not you asked for it. When the hosted check runs it does not send a summary: tool names go up with their inputs, which include file paths and commands exactly as they appear in your trace, plus up to 2,000 characters of each tool's output, inside a rendered view capped at 120,000 characters. Only the main session goes into that view: from boxdawn 0.5.21 submit also uploads a session's sub-agent files, which are analyzed for cost and resends and are not sent to the model. It also carries what you asked for: the text you typed to the agent, de-duplicated and in the order it appeared, at the top of the view. Tool results are not included, even though the trace format records them under the user role. The model's answer is not written to our database, so this is a transfer and not a second copy. That is the same data we keep out of our database on purpose, which is why this section names it instead of summarising it. Copies of boxdawn 0.5.23 and earlier also include boxdawn analyze, which runs on your own machine and sends nothing to a model unless you pass --verification yourself, with your own key.
The guard plugin for Claude Code
The Boxdawn guard is a Claude Code plugin that checks a command before it runs. It comes in two editions that check commands the same way. The edition in our own plugin marketplace, from the boxdawn/guard repository on GitHub, carries the guard program inside the plugin, so installing and updating it are downloads Claude Code makes from GitHub. The edition for Anthropic's plugin directory, from the boxdawn/guard-plugin repository, does not. Instead, when a Claude Code session starts and the guard program for its version is not yet in the plugin's data folder, it downloads one file for your machine from the boxdawn/guard release on GitHub, checks its SHA-256 fingerprint against the value written in the plugin, and uses it only if they match, then deletes the downloaded file. A file that does not match is discarded. This download happens once per version, with or without an API key. The request to GitHub carries no command, file path or key; as with any request over the internet, GitHub receives the IP address it comes from. Until the download succeeds, the guard cannot run, and Claude Code blocks Bash and PowerShell commands. This section describes version 0.1.1 of both editions. The check runs on your own machine. Apart from that download, without a Boxdawn API key, which is the default, the guard makes no network connection while you use it, and the commands it checks do not leave your machine.
If you give the guard an API key
If you enter a Boxdawn API key in the plugin's settings, the guard makes one request in the background when a Claude Code session starts. Its purpose is to confirm that the key belongs to a project on a paid plan and, if it does, to send the plugin its current rules. What is sent: the key, in the Authorization header, and an empty body. The command you were about to run, file paths, your conversation and any record of what the guard decided are not sent. As with any request over the internet, the service also receives the IP address the request comes from; our code does not record it. What we keep: our server checks the key by its hash, looks up the project and plan, and records the time the key was last used. That time is stored on the key's record, in the same database as your account (see where your account and measurements are kept), and any use of the key updates it, not only the guard. Revoking a key stops the updates but keeps the record, including that time. The site does not yet offer a way to delete a key, a project or an account. If you email contact@boxdawn.com from the address of the account the key belongs to and ask, we delete that key's record, including the last-used time, within seven days. The key then stops working and no longer appears in your key list, and the next time a Claude Code session starts, the guard is refused and deletes its rules file. Measurements are kept with the project, not with the key, so none are lost. Our code keeps nothing else from this request, except that if the lookup fails the server writes one line naming the kind of error, without the key, the command or any path, to its log. The request goes to the same Modal-hosted service as an upload (see where the analysis runs), and whether Modal's own request logs keep it, and for how long, we have not confirmed. What is kept on your machine: if the project is not on a paid plan, the request is refused and nothing is returned. If it is, the server returns a signed rules bundle, which the plugin saves as rules.json in its data folder. The bundle does not contain your key, only a fingerprint derived from it (an HMAC), which lets us tell which key a bundle was issued to if a copy turns up elsewhere. After seven days the bundle expires: the guard stops using it and falls back to its built-in rules, but does not delete the file. The plugin deletes the file when our server refuses the key. If you remove the key from the plugin's settings, the plugin stops asking and leaves the file, so it keeps using those rules until they expire. While it decides with those rules, the guard also keeps a log on your machine: each time it blocks a command or asks you about one, it writes one line to a dated file in a log folder inside its data folder. A line records the tool (Bash or PowerShell), whether it blocked or asked, whether an ask was turned into a block, the IDs of the rules that matched, what kind of target was involved (for example inside or outside the project), the time, when the rules expire and the plugin build. There is no field for the command itself, file paths or anyone's name. Commands it lets through are not logged, and on the built-in rules, with no key or an expired bundle, nothing is logged. The log is not sent anywhere. Log files older than 30 days are deleted the next time the guard checks a command, and the whole log folder is deleted when our server refuses the key. Claude Code's own help text says that uninstalling a plugin removes its data folder unless you pass --keep-data; we have not tested this.
Trace bodies are never in the report
The analyzer is invoked with --no-snippets, so prompt text and tool output from your trace are not included in the report at all.
What the report does contain
A report can contain file paths and commands taken from your own trace: which file was read twice, which command ran again. Those are not masked, because that is the finding. The report is returned to the browser that asked for it. On a one-off upload that is the only place it goes: no share links, no history, nothing to come back to. On a connected project we do not store the report file either, but it does not disappear when you close the page: the report comes back as the result of a background job on Modal, and Modal keeps that result fetchable for up to seven days before it expires. The ticket your browser uses to fetch it does not expire on its own, so anyone holding that ticket can fetch the report during those seven days. What we keep is a set of measurements derived from it (counts, sizes, costs) plus salted hashes of the targets.
If the analysis fails
A failure returns diagnostic output. That output is sanitized before it is returned or written to logs: caller-side file paths, email addresses, and secret-shaped strings such as API keys and bearer tokens are masked. The report body itself is deliberately left unmasked, for the reason above.
Limits
One file per analysis, .json or .jsonl. Up to 10 MB on a one-off upload, which runs while you wait; up to 16 MB on a connected project, where the run happens in the background and this page polls for the result. From boxdawn 0.5.21, boxdawn submit sends a Claude Code session together with its sub-agent files, and the 16 MB counts them all together.
Questions
Email contact@boxdawn.com, or open a GitHub issue.
Claims on this page describe implemented behavior. We do not claim encryption at rest, anonymization, or regulatory compliance that we have not built and verified.