Does TOVIO phone home?

No. TOVIO software does not report to the project in the background. Nothing counts your commits, times your commands, or notices which repositories you open.

That is the honest headline. The rest of this article is the detail behind it, including the one place where the software reaches the network without a command from you, because a privacy claim that skips that is not worth reading.

There is no telemetry, and no code to disable

The shipped CLI, editor extensions, and desktop app contain no analytics uploader, no crash reporter, and no beacon of any kind. There is no setting to find and switch off, because there is nothing to switch off.

The commitment underneath that is narrower to state and does not change: repository content, file contents, file names, paths, diffs, commit messages, lane and change names, identity keys, tokens, policy text, and audit data are never transmitted to the project, under any setting. If anything about that ever changes, the change is itself a recorded decision and a release-note item rather than a quiet default.

What leaves your machine, and only when you act

• Sync, clone, push, pull — to the remote you configured, over TLS 1.3. Protected paths travel as ciphertext; unprotected paths do not. Once a remote exists, some of this happens automatically; see the next section.
• Serving. tovio serve is the opposite direction: it opens a listener so peers you authorize can reach the repository on your machine. It sends nothing on its own, but it is the one command that makes your machine reachable, so it belongs on this list.
• A feedback link you click. It opens a TOVIO-owned page and carries at most four values. See What the feedback portal collects.
• An update, if you install one. See below.
• Conflict resolution with a model, if you explicitly ask for it. Running tovio resolve --ai with a model provider configured sends the conflicting file contents to that provider. It never happens without that flag.
• An agent you connect. If you run the MCP server and point an AI client at it, that client reads repository content and forwards it to whatever model backs it. TOVIO is the source rather than the sender — but the content still leaves, and the honest place to say so is here.
• Anything you send — a post, an email.

Automatic sync is the exception to "only when you act"

Once a repository has a remote, automatic sync is on by default. It is not telemetry and it does not reach TOVIO — it reaches the host you named — but it is network activity you did not type a sync command for, so it belongs in an honest answer.

It is not a background timer. A sync round runs after one of a small set of commands succeeds — commit, land, switch, tag creation, cherry-pick, revert, rebase — and no more often than a throttle interval allows. Editing files all afternoon without running one of those commands produces no network activity at all.

Publication is treated more carefully than fetching. Under the default push mode the first push of any lane is a manual act, only a lane you have already pushed by hand becomes eligible afterwards, and a protected lane is skipped. There is one exception worth knowing: setting sync.auto.push to all opts into pushing every local lane and drops both of those protections, which is why it is not the default.

Turn the whole thing off with sync.auto = off in the repository config, the --no-sync flag, or the TOVIO_NO_SYNC environment variable; set sync.auto.push = off to keep fetching but never publish automatically. A repository with no remote configured contacts nothing.

Update checks, stated precisely

A vague answer here would be worth nothing, so:

• The CLI has no update check. There is no update command and no update endpoint in it.
• The VS Code and JetBrains extensions have no update check of their own. Your editor updates its extensions on its own terms; that is the editor's behaviour, not TOVIO's.
• The desktop app ships a signed self-update mechanism, and on the current build nothing invokes it. Registering it makes the API available; it reaches no network on its own, and no check runs at startup or on a timer.

When an update is actually performed, the app fetches a small signed manifest from the public release host and, if you accept, the installer itself. That request carries no repository, no path, no identity, and no usage. It is still an ordinary HTTPS request, so the host serving it sees your IP address and the fact that you asked — exactly as it would for any download, and we would rather say so than imply otherwise. The manifest is verified against a public key compiled into the app, and an unsigned or wrongly signed payload is refused.

Because no automatic check exists today, there is no setting to turn one off. If one is ever added, it arrives with an off switch and a release note.

Plugins get no network at all

This is stronger than "off by default". The plugin sandbox defines no network functions, so a plugin cannot open a connection — there is nothing for it to call. A binding that asks for network access is refused rather than honoured. Network-capable plugins are a deferred decision, not a hidden switch.

Verifying rather than trusting

The engine, CLI, SDKs, and specification are Apache-2.0. Everything above is readable in the source, which is the reason for making the claim there rather than only here.