We spent an afternoon proving that OpenJarvis reports usage to a server in Virginia, found the undocumented switch that stops it, and confirmed with a packet sink that the switch works. Then, feeling pleased with ourselves, we ran the same inspection against OpenCode, the coding agent we have used every day since March. It ships a hard-coded crash-reporting endpoint, initialises it unconditionally at startup, and offers 41 environment flags to turn other features off, none of which touch it.
The tool we investigated has an off switch. The tool we trusted does not.
Both of these run local models. Neither sends your prompts anywhere. That is the part people get wrong when they hear “telemetry,” and it is worth separating from what is actually true, which is more interesting and more awkward.
Does OpenJarvis send your prompts to Stanford?
No, and we tested it rather than trusting the documentation.
OpenJarvis ships external analytics enabled by default. posthog is a runtime dependency of both of its virtual environments, and its config module carries a hard-coded project key and a host, flushed every 30 seconds. We redirected that host to a listener on 127.0.0.1, started the server, and asked a single question whose expected answer was the word “pineapple.”
Exactly one HTTP request left the machine. It was an event named chat_session_ended, and it carried a turn count, token counts, two latency percentiles, tool counts, an error count, a duration, a hashed model name, the operating system, the Python version and the analytics library version, identified by an anonymous install UUID. The word “pineapple” appeared nowhere in it. Neither did the question. There was no message content field at all.
Then we set enabled = false under an [analytics] heading in ~/.openjarvis/config.toml, restarted, and sent the identical question to the identical model. Nothing left. Zero requests.
So the payload is counters, and the switch works. The failure is documentation. docs/telemetry.md opens by promising to explain “how to opt out” and contains no opt-out section. The single control it names, jarvis analytics reset-id, does not exist: the underlying function sits in the source with nothing wired to it, and there is no analytics subcommand at all. The switch we used is real, verified, and written down nowhere.
Does OpenCode phone home too?
Yes, and we did not expect it to.
OpenCode is an Electron app. Its code lives in a 93 MB app.asar archive inside the bundle. Inside that archive, at renderer startup, in a bare block with no environment check and no configuration lookup:
init$1({
dsn: "https://2fe8...@o4511072101138432.ingest.us.sentry.io/4511210181885952",
environment: "production",
release: "desktop@1.16.2",
integrations: (integrations) => integrations.filter(i => i.name !== "Breadcrumbs")
})That is Sentry, with a production DSN compiled into the shipped build. It is not gated on a debug flag, a first-run consent prompt, or a setting.
It is also not only crash reporting. Sentry auto-enables nine integrations in the browser SDK, one of which is browserSessionIntegration, whose job the integrations reference describes as tracking healthy sessions in the browser. The list compiled into OpenCode’s bundle matches that reference exactly, and OpenCode’s filter removes precisely one entry from it, Breadcrumbs. Release-health sessions therefore stay on, which by the SDK’s own design means a session envelope is sent when the app starts, whether or not anything goes wrong.
We looked for a way to stop it. The bundle ships 41 distinct OPENCODE_DISABLE_* environment flags. You can disable project config, model fetching, autoupdate, the embedded web UI, external skills, the mouse. Not one of them mentions telemetry, Sentry, or analytics. There is no DO_NOT_TRACK, no OPENCODE_TELEMETRY, no configuration key. We found nothing.
Strings extracted from OpenCode desktop 1.16.2 app.asar. StrideNote inspection, 8 July 2026.
Two things are worth saying in OpenCode’s favour, because the point is accuracy and not a verdict. sendDefaultPii is never set in that init call, and Sentry’s options reference gives its default as false. And Breadcrumbs being explicitly stripped is a deliberate privacy decision by somebody who thought about it: breadcrumbs are what would otherwise capture console output, DOM interactions and user actions in the moments before an error.
But an error event carries a stack trace. In a coding agent, a stack trace is the payload most likely to contain a file path, a project name, or a fragment of the thing you were editing. OpenJarvis explicitly drops file paths through a redaction layer with more than twenty patterns. OpenCode makes no such promise, because OpenCode makes no promise at all.
Which one is actually more private?
Put the two side by side and the answer inverts the intuition.
| OpenJarvis | OpenCode | |
|---|---|---|
| Reporting endpoint | PostHog, hard-coded key and host | Sentry, hard-coded DSN |
| When it fires | Every 30 seconds during use | On startup, and on error |
| Payload we observed | Counters, hashed model name, no content | Not captured; stack traces by design |
| Sends file paths | No, dropped by a redaction layer | No stated position |
| Documented | Yes, in a page whose opt-out section is missing | Not that we found |
| Working off switch | Yes, undocumented, verified by capture | None found |
Studio test machine: Apple M4 Pro, 48 GB unified memory. StrideNote hands-on testing, 8 July 2026.
Both ship a hard-coded reporting endpoint. Only one of them can be switched off. StrideNote inspection, 8 July 2026.
The research project from a university lab discloses what it collects, redacts aggressively, and hides the switch. The commercial coding agent discloses nothing and ships no switch. Neither of them wants your prompts. Only one of them can be made quiet.
There is an honest limit on that OpenCode row. We read the shipped bundle; we did not capture a packet from it, because doing so means repointing a DSN compiled into a signed archive. The startup session claim follows from the SDK’s documented default integrations and from OpenCode’s own one-line filter over them. We are confident, and we have not watched the bytes leave. That distinction cost us three wrong verdicts in a week, so we are keeping it.
What does this cost you at the prompt?
Privacy is not the only axis, and on the axis we chose these tools for, they are not close.
OpenCode’s system prompt runs to roughly 51,700 tokens, which is why its local model must be loaded with at least a 64K context window before it will answer at all. OpenJarvis’s command line defaults to an orchestrator agent that spends 4,438 prompt tokens on a six-word question. Its desktop app runs a simple agent and spends none.
Yellow is what we run daily. Black is what we tested and removed. StrideNote hands-on testing, 8 July 2026.
Those numbers measure ambition, not waste. OpenCode’s prompt buys tool calling, file editing and a skills system, and it is the reason a 31B model at 64K context is the floor for our local AI stack rather than a nice-to-have. OpenJarvis’s simple agent buys a fast answer and nothing else. Neither is wrong. They are different machines.
We removed OpenJarvis anyway. Not because it spies, since it does not, and not because it is broken, since it is not. It is 936 MB of duplicated code and 26 GB of models we never asked for, filling the assistant slot that our Hermes agent already occupies, on a machine where the engine question was settled months ago.
OpenCode stays, with a Sentry DSN we cannot switch off and a stack trace we have not read. The next thing to check is not OpenJarvis. It is Hermes, and Pi, and everything else we told ourselves was local because we installed it ourselves. Local model does not mean local software. We ran the test on the tool we distrusted and it passed. We had never once run it on the tools we trusted.