← Back to tyfold.com

Privacy Policy

Last updated: 29 September 2026

Tyfold is a local-first desktop app. Your terminal sessions, prompts, code, and provider credentials stay on your own machine. It also records crash and usage diagnostics; those are written to your own disk, and nothing reaches us unless you switch reporting on (see §5). The only personal data we hold is your early-access sign-up, if you make one: the email you give us, and the few things recorded with it (see §7).This website uses privacy-friendly, cookieless analytics that can't identify you (see §7).

1. Who we are

Tyfold ("Tyfold", "we", "us") is a commercial desktop application. For the limited personal data described below, Tyfold is the data controller, and you can reach us about privacy at privacy@tyfold.com.

2. The short version

  • The app is local-first. Everything you do inside Tyfold stays on your device: your terminal input and output, your prompts, your code. None of it is sent to us. Your settings and session layout stay on your machine too, with two caveats §3 sets out: a short list of your settings rides along with usage reporting, if you have that switched on, and a settings sync between your own machines is a possibility we are considering.
  • Crash and usage diagnostics are recorded on your machine. Tyfold writes a report when it crashes, and one when it freezes. If you switch reporting on, it also records which features you use, and it sends all three to us. Nothing is sent while that setting is off, and off is where it starts. See §5 for what a report holds, where it goes, and how long it is kept. There is no advertising, and we do not sell or share anything with anyone.
  • Tyfold makes three calls of its own accord to servers that are not yours, and only one of them carries anything about you. Two happen at startup and are anonymous: a check of whether early access is still open, and a check for a newer version, repeated every two hours while Tyfold is open. Neither carries an account, an identifier, or anything from your sessions. The third only happens if you switch reporting on, and it is the diagnostics described in §5; it carries a random identifier for your installation and nothing else about you. Everything else is your own CLI talking to your own provider, a download you asked for, or an SSH connection to a machine of yours (§4).
  • The only data we hold is your early-access sign-up, and only if you choose to make one, so we can tell you when Tyfold is ready and send you your founder discount when Pro launches. That is your email address, plus the date, network address and referring page our form provider records with it and we never use (see §7).

3. Data that stays on your device

Tyfold is a client that drives your own local command-line tools (such as Claude Code) under your own provider credentials. All of the following is processed only on your computer and is never transmitted to us:

  • the content of your terminal sessions (input and output);
  • the prompts you write and the responses your LLM returns;
  • your files, code, and anything shown in a session;
  • your provider credentials and API keys. Tyfold reads them from your local environment to launch your CLI. They never reach us, and we never act as a middleman between you and your provider. One narrow thing you can switch on uses a key to talk to the provider it already belongs to. See the paragraph on usage meters below.
  • an SSH password or key passphrase you tick Remember for. It is kept in your system's password store (Keychain, Credential Manager, or the Secret Service on Linux) and used only to answer that host's login prompt. Tyfold's own files record which hosts have one saved, never the secret.

This section is about how Tyfold is built, not about what we have got round to yet. Your sessions are not held back from us by an unfinished feature; the app has no notion of sending them. Three things are a different matter and have their own paragraphs: crash and usage diagnostics (§5), your settings, and the usage meters, both below.

The usage meters, if you switch them on. Tyfold's status bar can show how much of your plan's allowance you have used. For Claude that costs nothing extra: Claude Code already reports its own figures to the app. OpenCode publishes no such figures anywhere Tyfold can read them, so the only way to fill those meters is to ask OpenCode for the numbers using your own OpenCode key. That is off unless you turn it on, at Preferences → Usage → "Read my OpenCode Go usage". With it off, nothing reads your key and no request is made. With it on, the request goes from the session's own opencode process straight to OpenCode, at most once a minute, carrying your key so they know whose allowance to report. The key goes only to OpenCode, who issued it and already hold it. It never reaches us, it is not written into any report or log, and only the resulting percentages are shown on your own screen. Apart from an SSH password you chose to save, this is the one case where Tyfold uses a credential for anything other than starting your CLI, which is why it asks first.

Your settings and session layout. These live on your machine, in your operating system's standard application-config directory. One narrow thing leaves, and only with your consent: if you have usage reporting switched on, Tyfold sends a list of which settings you have chosen, once each time it starts, so we can see which options people actually use. That list covers things like the theme, which side the rail is on, and the terminal font size. It is a snapshot and not a sync. Nothing comes back, nothing on your machine is changed by it, and with reporting off it is never sent at all.

A setting is sent only if its possible values are written down in the code. That means a yes or no, a number within stated bounds, or one of a fixed set of names, and the value is checked against that list immediately before it is sent. Anything you typed yourself is left out by the way the rule works rather than by anyone's judgement about whether it looked safe enough: session names, folder paths, commands, your own labels, colours and font names have no fixed set of values, so they do not qualify and cannot be added by deciding they seem harmless.

Separately from that, we are considering an optional settings sync that would copy your Tyfold settings between your own machines. It does not exist, it may never be built, and it is not on this list of things the app structurally cannot send. If it is built it will be something you switch on, it will cover settings only and never the session content above, and this policy will describe it before it ships.

4. Data Tyfold sends off your device

Tyfold is local-first: the app does not send us your sessions, prompts, or code. (Crash and usage diagnostics are the exception, and the short list of settings described in §3 rides with them. §5 sets out what they hold, where they go, and what we commit to.) The only unavoidable exposure is your IP address. Like any internet-connected app, it is revealed to whichever server the app connects to. We don't use your IP address to profile or track you.

Tyfold makes three calls on its own to servers that are not yours. Two happen whenever it starts, and the update check repeats every two hours while Tyfold is open:

  • An early-access check, to us. It asks whether the early-access period is still open. The request is anonymous and unauthenticated: it sends no account, no identifier, and no content from your sessions, and it travels over an encrypted connection.
  • An update check, to us. Tyfold asks which version is the latest, so it can tell you when a newer one exists. Like the check above, it is anonymous and unauthenticated: no account, no identifier, no content from your sessions, over an encrypted connection. The download itself still comes from GitHub, and only once you click it. On Linux, Tyfold can then fetch the package for you, check it against the checksum in that signed answer, and hand it to your package manager. Your desktop asks for your password first, and nothing is installed if you dismiss that prompt.

The third happens only if you switch reporting on:

  • Diagnostics, to us. If "Send crash & usage reports" is on, Tyfold sends the reports described in §5, shortly after it starts and every half hour after that, and only when there is something waiting. The request carries no account and no licence key. It does carry a random identifier for your installation, which is the one thing on this page that persists about you, and §5 sets out what it is for and how to reset it. With the setting off this call never happens at all.

Anything else that leaves your machine goes somewhere you chose: your own CLI talking to your own provider, downloading Tyfold, downloading a terminal font from Preferences, or a machine of yours you opened over SSH.

Not every SSH connection waits for a click. Once a session or folder on another machine is open, Tyfold reaches it again on its own with your ssh: to copy a Claude session's replies back to your screen, including when Tyfold starts, and to save and later delete the file snapshots that View changes shows. These go only to that machine. Nothing reaches us.

5. Crash reports and usage data

Tyfold records three kinds of diagnostic:

  • Crash reports. When the app hits an error it writes a report to a diagnostics folder inside its config directory. This happens whether or not you have opted into anything, the same way most desktop applications keep a local crash log.
  • Freeze reports. If the app stops responding, it writes a report to the same folder, and another one if it recovers. A freeze produces no crash report, because nothing has crashed, so without this there would be no record that it ever happened.
  • Usage data. If you turn on "Send crash & usage reports" in Preferences, Tyfold also records which features and screens you use, and the short list of settings described in §3. This one is off until you switch it on.

A crash or freeze report holds the app version, your operating system, kernel and processor architecture, your webview version, and how many sessions were open at the time. A usage record is lighter and holds none of that: the app version, how many sessions were open, and the feature counts or settings the record is about. One of those records sums up a run of the app, from launch to quit, so it also holds how long each session in that run was running and the most you had running at once. How long, never when. Every delivery carries two things of its own, whatever it holds: the app version, and the name of your operating system, one of linux, macos or windows. That is how we can tell how many people are on each, which we otherwise could only guess at from the machines that crashed. It is the name and nothing else: not the release, not the kernel, not the machine. A crash report also holds the error message and the stack trace of the code that failed, because without them a crash report is of no use. A freeze report also holds how long the app was unresponsive, which part of it stopped, and the names of the last few internal operations it ran, with names like git_log or fs_read_file, and how many times each of them ran. If the app recovers, that report also names which of a fixed list of its own jobs kept it busy, such as status-scan, with how long they took in total and how many times they ran. Those are the names of operations and never what was passed to them: no file paths, no search terms, no commands you typed. None of the three holds prompt content, terminal output, or file contents.

Each report carries a random identifier for this installation. It is a random value made on your computer the first time anything is sent. It is not your name, not an account, and not linked to one, and you can throw it away and get a new one at any time in Preferences → Privacy. We will not tell you it identifies nobody, because that would be a word game: an identifier that stays the same across months is still about you, even with no name attached. It is there for one reason, which is to tell twenty reports from one person apart from one report from twenty people. Reset it and everything sent afterwards is unconnected to everything sent before.

Beyond that we do not put anything identifying into these records. One honest caveat: an error message is written by the code that failed, and can contain details from your machine, such as a file path that includes your account name. Before a report is sent, Tyfold removes file paths, web addresses, user@host addresses and the server names in connection errors. It will miss some. A server name worded some other way, or a path written relative to a project folder, can still get through.

Where the reports go. If you switch sending on, Tyfold sends them to its own collector, which runs on Amazon Web Services in Ireland. Nothing else receives them, they are not sold or shared, and there is no advertising anywhere near them. The request carries no account, no licence key and no name, and the server is built not to read or keep the network address it arrives from. Reports are deleted after a year, by the store itself rather than by anyone remembering to do it. If sending is off, nothing is transmitted at all; the reports sit in a diagnostics folder on your machine, which you can read and delete whenever you like.

What we commit to. Nothing is sent unless you switch reporting on, and it starts off. Beyond that, what gets sent stays inside what this section and §3 describe. Both will grow as the app does, and that growth is already covered: a new count is still a count of which features and screens you use, and a new setting still has to pass the rule in §3 before it can be included. We are not going to list every counter here, because a list like that goes out of date faster than anyone updates it, and a boundary you can hold us to is worth more than an inventory that quietly stops matching the app. What the boundary excludes is anything of a different kind: anything taken from the content of your sessions, files or prompts, a record of when you did something rather than how often, and any setting value that does not come from a fixed list. If we ever want to send one of those, this page will say so before the first one is sent, not after.

6. Your LLM provider

Tyfold drives your own LLM tools under your own account. When you use a session, your prompts and data go directly from your machine to your chosen provider (for example Anthropic, for Claude Code) under your own credentials. Tyfold does not sit in the middle of that exchange. What that provider does with your prompts is governed by their terms and privacy policy, not this one. Tyfold is an independent product and is not affiliated with or endorsed by Anthropic.

7. This website

tyfold.com is a static informational site that sets no cookies. For basic traffic measurement it uses Plausible Analytics, a cookieless, EU-hosted analytics tool. It counts page views, referrers, and a small number of anonymous interaction totals such as how many people submitted the sign-up form. All of it is in aggregate only. It records no information you type, the address you enter included. Plausible sets no cookies, stores no personal data, does not retain your IP address, and cannot identify you or follow you across other sites. There is no advertising or cross-site tracking.

The only thing the site asks you for is your early-access email. If you choose to enter your address, we use it only for two things, nothing else:

  • to tell you about major Tyfold releases, such as the macOS and Windows versions, and
  • to send you your lifetime founder discount when the paid Pro tier launches, because you signed up during early access.

The form is handled on our behalf by Buttondown, an email service provider based in the United States, which stores your address so we can reach you and processes it only on our instructions; the legal basis is your consent. Because this moves your address outside the EEA/UK, the transfer is covered by the European Commission's Standard Contractual Clauses. Signing up is entirely optional, we never sell or share the address, and you can withdraw at any time by emailing privacy@tyfold.com, or from the unsubscribe link in any newsletter we send, after which we delete it.

Submitting the form records a little more than the address itself. Alongside it, Buttondown keeps the date you signed up and, from the submission, your IP address, the country it places you in, and the page you submitted from. We do not ask for any of it and we do not use it: it is how Buttondown dates a subscription and screens out automated sign-ups. It is deleted with the rest of your record when you unsubscribe or ask us to remove you.

Diagnostics, if you switch them on, are received and stored by Amazon Web Services in Ireland, acting on our instructions and nobody else's. They stay in the EU: the service that receives them runs in an EU region, with no content delivery network in front of it, so a report does not travel through anywhere else on its way. The legal basis is again your consent, which is the setting in Preferences, and withdrawing it stops the sending immediately.

Separately from the sign-up record described above, our hosting and form providers may keep standard server access logs (including IP addresses) for security and operational reasons; those are not used to identify or track visitors. The diagnostics endpoint is the exception in the other direction: its access logging is switched off, and the code that receives a report is written not to read the network address it came from.

8. Data retention

Diagnostics are deleted after a year. That is done by the store itself, on a timer attached to each report when it arrives, rather than by anyone remembering to run something.

The other personal data we hold is your early-access sign-up, if you made one: the email address, and the signup date, IP address, country and referring page recorded with it (§7). We keep it until both of the things in §7 are done (you've been told the build is ready, and your founder discount has been sent once Pro launches), or until you ask us to remove it, whichever comes first. Then we delete it. Because the founder discount is the reason you signed up, that can mean holding your address until Pro actually launches; you can withdraw at any time and we'll delete it immediately. On-device data lives on your machine and is removed when you delete it or uninstall the app.

9. Your rights

If you are in the European Economic Area or the UK, you have the right to access, correct, delete, or restrict processing of your personal data, to object to processing, and to data portability. To exercise any of these, email privacy@tyfold.com. You also have the right to lodge a complaint with your local data-protection authority.

10. Age

Anyone can use Tyfold, at any age. It's a coding tool, open to everyone. This section only concerns the limited data we collect (see §7): if you are under the age of digital consent in your country, please don't submit your email for early access without a parent or guardian's involvement. We don't knowingly collect children's personal data without appropriate consent, and will delete any such data on request.

11. Changes to this policy

We may update this policy as the product evolves. Material changes will be reflected here with a new "last updated" date. Continued use after an update means you accept the revised policy. Where a change means data starts leaving your machine that did not before, we will describe it here before that starts, and ask for your consent. See §5.

12. Contact

Questions about this policy or your data: privacy@tyfold.com.