TESI is the ToolsEnabled site. This page is developer tools. Tools · TEAA account

Privacy

Applies to ToolsEnabled Fleet 1.11, the other ToolsEnabled products named below, the ToolsEnabled account, and this website. Updated 22 October 2026.

ToolsEnabled Fleet plugin

This statement covers the ToolsEnabled Fleet plugin. It does not describe other ToolsEnabled products or the privacy practices of any AI provider.

Data kept on your computer

Fleet keeps its setup choices, tasks, ledger records, memory, search index, subagent records, conversation history of the subagents it starts, settings, launch files for each subagent (generated settings and, where its CLI needs one, a copy of that CLI's model list), the computer's hostname in a machine record and, with audit on, its signed audit log and the log's signing key in its private state folder, ~/.toolsenabled-fleet-plugin by default (or the folder you set in TOOLSENABLED_FLEET_STATE_ROOT). These records can contain prompts, file excerpts, tool arguments and results, and anything you or an agent choose to save. Every agent connected to the same Fleet setup can read them.

Fleet also keeps two kinds of local diagnostic log in its state folder, under logs/: the error output of each Claude Code subagent (up to 256K characters per file, the newest 50 files kept, with the sign-in secrets in your environment removed; Fleet cannot recognize a secret it never sees, such as one inside a CLI's own saved login), and a short record of how each Fleet server process ended (its process details, versions, memory use, how many requests it served and the name of the last tool called, never a tool's arguments). Error output is whatever the agent CLI printed, which can include file paths and error messages. These logs never leave your computer; check them before sharing.

Claude Code's plugin data folder (or, without one, Fleet's state folder) holds the ID, not the words, of a standing rule you just added until your next message, and a change waiting for your one-time code, with only a digest of the code. Fleet also makes private socket folders for its subagent tree, $XDG_RUNTIME_DIR/tef/<hash>/ or /tmp/tef-<uid>/<hash>/; they are temporary.

With audit off, the default, Fleet keeps no audit record: no signing key, nothing signed. With audit on, it signs a record of the reads and writes of Fleet's own file tools, ledger changes, task and memory changes, and subagent starts, stops, resumes, restarts and removals it makes; the agent CLIs' own file tools, which do not go through Fleet, messages sent between subagents and read-only calls, such as reading tasks, memory or the ledger, are not recorded. If an earlier Fleet 1.6 kept your audit key in the login keyring, Fleet never reads that keyring. The first time audit is used with audit on, Fleet moves the earlier history to audit-history-keyring-<id> in Fleet's state folder, with its files read-only, and starts a new signed history. Deleting the state folder deletes it too, and rm -rf of the state folder works. The old keyring entries stay in your keyring, and you can delete them there.

The agent CLIs Fleet starts as subagents also keep their own session history, in their own folders (for example ~/.claude for the Claude Code CLI, ~/.codex for the Codex CLI and ~/.local/share/opencode for the OpenCode CLI), as they do for any session you run.

Fleet 1.7.2 to 1.7.5 read the sign-in settings in the user settings file of the CLI that hosts Fleet and copied sign-in commands from it into the generated settings file of each subagent run by that same CLI, in Fleet's state folder. This version never reads that file and, the first time it starts, removes those copied commands from the generated files. If a key was ever written inside such a command, treat it as exposed to the files of your own account and rotate it.

Your standing rules are also passed to each subagent on its command line, so another account on the same computer could read them from the process list unless the system hides other accounts' processes.

What Fleet sends

Fleet sends nothing to ToolsEnabled. It has no telemetry, no crash reporting and no ToolsEnabled account or hosted service. Fleet's search runs on your computer.

The agent CLIs Fleet starts as subagents (the Claude Code CLI, the Codex CLI or the OpenCode CLI) communicate with their own providers under your own sign-in. They can send prompts, tool results and file content to those providers under your account and the providers' terms. Subagents sign in exactly as each agent CLI does in your terminal: with its own saved login, or with the sign-in variables you set for it (an API key or token, a cloud provider's variables, a gateway's address and token), which Fleet leaves in place for the agent CLIs it starts. Fleet itself never writes, stores, logs or sends a sign-in value; it holds the values only in memory, to remove the secret ones (keys, tokens, passwords, credentials and each CLI's own sign-in variables) from an agent CLI's error output, messages and errors before keeping or showing them; a setting that only chooses a provider, region, profile or address is not a secret. From the agent CLIs Fleet removes only what ties a process to your own session, Fleet's own internal variables, and OpenCode's configuration variables other than its sign-in ones. Claude Code starts Fleet's MCP server, its two hooks and the panes' programs with its own environment, as it does for every plugin, and Fleet passes the variables on, unread, through the processes that start an agent CLI (its session runtime, setup's sign-in check and protocol probe, and its process supervisor, over a pipe). Every other program Fleet starts for itself gets no sign-in variable: the provider sign-in variables, and every variable with KEY, TOKEN, SECRET, PASSWORD, PASSWD, PASSPHRASE or CREDENTIALS as a word between underscores in its name, are removed from them. A sign-in kept only in a settings file that a subagent does not load is not used: a Claude Code subagent loads none of your user, project or local settings files (managed settings still apply). Subagents have no shell. During setup, Fleet runs each installed agent CLI's own sign-in status command (and, where the CLI runs subagents in its own sandbox, a check that starts that sandbox around /bin/true with no model call), the way a subagent starts it, and uses only whether they succeeded and whether a sandbox reported that it could not start; that CLI may contact its provider to check, as it does when you run the command yourself. These checks run again on their own after an update and when you change providers or models.

Subagent reports are written under .fleet/reports/ in your project folder.

Fleet's prompt hook receives each prompt in a session where the plugin is on, only to recognize /tefleet ledger, /tefleet settings and /tefleet confirm, which Fleet applies itself without sending them to Claude. It keeps nothing else, except a change waiting for your code, with only a digest of the code, for 5 minutes (in Claude Code's plugin data folder or Fleet's state folder). It does not send other prompts anywhere; a ledger command's words are saved in your ledger, and a settings change in Fleet's settings, in Fleet's state folder. At the start of each session in Fleet's project, the hook reads your open standing rules from that ledger and gives them to Claude (Fleet also gives them to every subagent it starts), and the ID of a rule you just added is held until your next message carries that rule to Claude.

Fleet's tool hook (schedule-guard.js) reads CronCreate, CronUpdate, ScheduleWakeup, RemoteTrigger and SendMessage calls only to refuse one whose prompt begins with a /tefleet command; it keeps nothing.

The agent CLIs' own privacy policies

What an agent CLI sends to its provider is governed by that provider's privacy policy, not by Fleet:

When an agent CLI uses a cloud provider, a gateway or a model provider that you set up for it, that provider's own privacy policy applies as well, for example:

For a gateway or any other provider you configure, see that provider's own policy.

Removing data

Uninstalling the plugin keeps Fleet's state folder. Delete that folder yourself to remove Fleet's records, including any moved audit history; rm -rf of the state folder works. The old Fleet 1.6 keyring entries stay in your keyring until you delete them there. The agent CLIs' own session history for subagents stays in those CLIs' folders; manage or delete it with each CLI. Removing Fleet does not delete anything already sent to a provider; that is governed by the provider's own terms and settings.

Contact

Questions: support@toolsenabled.ai, or GitHub issues for anything that is not sensitive. Security problems: see SECURITY.md, which offers private reporting and a safe harbor for good-faith research.

Other ToolsEnabled products

The sections below are kept by this website and cover the other ToolsEnabled products one by one: TEAA, Fleet MCP, Sim, ToolsEngine and Data. Each runs on your own computer. Each section says what the product writes, what it sends and where its records live, as the product's released documentation describes, and links to that documentation at the released version. The versions named are the current releases on the date above.

TEAA

TEAA 0.5 brings Fleet, ToolsEngine and Knowledge together in one local MCP connection. It adds no telemetry, analytics or automatic update checks, and its gateway runs on your computer and does not send MCP traffic to ToolsEnabled. It starts Fleet, ToolsEngine and Knowledge as local programs and passes requests, results, progress and cancellations between them and your MCP host. Those tools keep their own settings: they can read or change workspace files and make network requests as their own tools and privacy notices describe, and a browser operation or a subagent can send information to the service or provider it uses.

Setup writes its configuration, its installed program files, Fleet’s state and Knowledge’s project repository in your user configuration and data folders on your computer. Knowledge keeps project context in a local Git repository there, with sync off and no network remote unless you add one. TEAA does not need a ToolsEnabled account, and it does not read provider credentials, choose accounts or sign in to an AI provider: your MCP host and any subagents sign in through their own supported flows. Your host sees tool results and may send them to its model provider. Uninstalling keeps your settings, Fleet’s state, Knowledge’s repository and your work. Source: README.md and SETUP.md in the TEAA 0.5 source, and its setup code.

Fleet MCP

Fleet MCP is a separate release of the Fleet engine, with its own version number, for agents that run it as a plain MCP server. It sends nothing to ToolsEnabled: it has no telemetry and no update check. Its own network use is limited to the model endpoints you configure, loopback model discovery and, when you use its sandbox policy tools, the sandbox host's policy service. It never signs in, reads, copies, stores or forwards an agent's sign-in, and the agents it starts talk to their own providers under your own sign-in. Its state lives in the folder its install notes name. What it runs, writes and sends is set out in the Fleet MCP notes on the Fleet page.

Sim

ToolsEnabled Sim 0.1.12 is a shared warehouse simulation for three or four wheeled robots: each agent controls one robot through MCP, and a coordinator assigns crates and advances the world in lockstep. You start its hub yourself with a private run root (node src/hub-cli.mjs --root /absolute/private-sim-run), and each agent's MCP host joins through a private connection file whose path the hub prints in its launch terminal. The hub listens only on 127.0.0.1, on an ephemeral port. An existing run root is refused unless it is owned by the hub user with mode 0700, and connection files are created with mode 0600.

What it writes: in the run root, one run-NNNN directory per run, created with owner-only modes, holding an append-only trajectory.jsonl (the world state after every physics step: robot poses, driving agent IDs, Fleet task and ledger IDs, held crates, contacts, accepted commands and score) and actions.jsonl (every accepted command with its bound identity, tool name and validated arguments), with scenario.json and work-record.json preserving the inputs, live.jsonl in live mode, and current-run.json and view-meta.json as private view metadata. Reset and scenario changes start a new run directory and keep the old logs. Wall-clock times, connection capabilities and filesystem paths are absent from the deterministic logs, but the logs contain assignments and actions, so treat them as private operational data. The optional capture command, which you run yourself, writes PNG frame sequences and a capture-receipt.json (frame hashes, browser version, executable SHA-256, platform and launch flags) to a new directory you name.

What it keeps, and for how long: everything Sim writes stays on your computer, in folders you choose, and ToolsEnabled keeps nothing. Nothing expires, and Sim never deletes a run: each run stays until you delete it. The hub keeps its runs in the run root you name with --root, a new run-NNNN folder for every run beside the earlier ones, and current-run.json, which stays after the hub stops. It removes its connection files and its lock file when it shuts down cleanly; after a crash they stay in the run root until you delete them. The demo and the capture command write only to the new folder you name for them, and capture deletes that folder again only if it fails before finishing. The plugin itself writes nothing: its MCP server and its pane reader only read the connection file and the run root. When Sim is installed as a Claude Code plugin, the paths you set for the connection file and the run root (not the files' contents) are stored in that installation's settings.json.

Uninstalling the plugin leaves the run root, its run folders and any demo or capture folders where they are; uninstalling it from Claude Code removes the stored paths. To remove everything, stop the hub, then delete the run root and any demo or capture folders you created.

What it sends: nothing to ToolsEnabled. No model, agent CLI, cloud service, browser or GPU is required for the simulation, no provider credentials or model calls are needed, replay runs without a model or internet connection, the package never downloads a browser or installs system packages, and screen capture, uploads and publishing are not available as MCP tools. The agents come from the MCP hosts you connect; what a host sends to its own provider is governed by that provider's terms, not by Sim. Sim has no dashboard or human-control link. Agent file or shell tools running as the same operating-system user can read host logs and private connection files; see Sim's SECURITY.md. Source: the README, docs/REPLAY.md and docs/CLAUDE-INSTALL.md at tag v0.1.12.

ToolsEngine

ToolsEngine 0.1.7 is a local MCP server for browser automation, workspace files and public web reading on Windows and Linux. Its file tools read and write only inside the one workspace folder you choose, and screenshots, PDFs, page snapshots, logs and downloads are saved there too, under artifacts/toolsengine by default, up to 256 files and 64 MiB in total. Of the page snapshots that browser calls write by themselves, ToolsEngine keeps the newest 64 and deletes older ones; nothing else is deleted automatically, so delete other saved files yourself to make room. Hidden files in the workspace, such as a .env, are readable like any other file, so choose a workspace that holds nothing the assistant should not read. The browser's temporary state goes under .toolsengine-runtime in the workspace, and the installer keeps its printed log and its settings beside each installed version.

By default the browser runs hidden with a temporary profile of its own: it does not open your everyday profile and has none of its sign-ins, and that temporary state is discarded when the browser closes on an orderly stop (a server that is killed outright leaves it behind, with that session's cookies, until you delete it). Sign-ins are reused only when you choose a dedicated profile folder with --profile-dir and sign in yourself; that profile then keeps its cookies and sign-ins. In the optional --browser-extension mode, the assistant acts in your everyday browser with your sign-ins, in a tab you choose and approve in that browser. The optional Windows desktop tools, off unless you install with --desktop, let the assistant read and operate the apps open on your Windows account, signed-in ones included.

What it sends: nothing to ToolsEnabled. No API key, account discovery, sign-in or other server is needed; installing downloads nothing, and the installer uses no network. web.fetch accepts only public HTTPS destinations by default (the startup option --allow-local-network adds HTTPS intranet addresses). The browser's own traffic goes to the sites you open, with normal browser network access, private networks included: it can disclose typed text, uploaded files and cookies from the selected session; web requests disclose the requested URL and network metadata to their destination; desktop input can cause the selected application to transmit data; and an installed browser can contact its maker on its own, independently of ToolsEngine. Tool results go to your MCP client, so file text, page snapshots, window text and unredacted images may be sent to that host's model provider and retained in its conversation or logs; ToolsEngine cannot determine that provider's retention or enforce its privacy settings. Uninstall keeps the workspace. Source: the README at tag v0.1.7, in particular "Data, storage and stopping".

Data

ToolsEnabled Data 0.8.9 is a plugin made and tested for Claude Code: a local data workspace that connects CSV and TSV files to a project so they can be inspected, checked, transformed and laid out as tables and charts. It runs entirely on your computer. Its own privacy notice is kept with its source, and this section mirrors it: PRIVACY.md at release 0.8.9.

It collects no telemetry, analytics or usage data, and ToolsEnabled receives nothing from it. It reads only the files, folders and documents you connect, and never modifies them. It stores its records in the .tedata folder of your project and its Python environment in its data folder on your computer. Its only network access is the one-time setup. Setup downloads DuckDB from the Python Package Index (pypi.org and files.pythonhosted.org), or from the package index your own pip or uv configuration names. If uv is installed, setup uses it, and uv may also download a Python interpreter (uv 0.12 downloads it from releases.astral.sh). Setup runs only from its data folder, never from the project folder.

Claude Code sees data only through the tool results it requests during your session; how its provider handles your conversations is governed by your agreement with that provider. Data has not been tested in cloud task modes, and its tools do not load in web chat. It never reads, stores or sends logins, tokens or keys: it refuses to connect or read files in credential locations (for example .aws, .config/gcloud, .ssh and keychains) or with credential names (for example .netrc, auth.json, .env and private key files), and it will not return a document whose text is a private key or a list of tokens.

It also refuses to connect or read files in AI agents' chat history and settings folders, including a folder set with an agent's environment variable and other accounts' folders of the same kind in your home folder; PRIVACY.md, linked above, lists each one. Files connected from these folders with an earlier version are no longer listed or read. A project that the host keeps as a git worktree inside its own folder is an ordinary project folder; the host's folder inside that project is refused.

What it keeps, and for how long: everything it writes stays on your computer, and ToolsEnabled keeps nothing. Nothing expires: it stays until you delete it. The project's .tedata folder holds the list of connected sources and documents, saved interpretations and views, preparation and collection records, and caches. These hold sample rows and summaries of your data. Derived copies and exports go to .tedata/derived-data and its exports folder, or to the derivedDirectory you set in .tedata/workspace.json, and to any folder you choose for an export; they are full copies of the data you transform or export. Its data folder holds its Python environment and setup record, with none of your data. It is the plugin data folder the host provides or, without one, ~/.local/share/toolsenabled-data on Linux or %LOCALAPPDATA%\ToolsEnabled Data on Windows; TEDATA_DATA_DIR overrides both.

Uninstalling it leaves .tedata, the derived copies and the exports where they are; uninstalling with claude plugin uninstall also removes the plugin data folder unless you add --keep-data, and a data folder elsewhere stays. To remove everything, delete the project's .tedata folder, any derived-copy and export folders outside it, and its data folder. Setup can also leave files in pip's and uv's own folders: their download caches keep the DuckDB package (pip cache purge or uv cache clean empties them), and a Python interpreter that uv downloaded stays in uv's Python folder until you remove it with uv python uninstall <version>.

ToolsEnabled account

This section covers the ToolsEnabled account at toolsenabled.ai/account and the hosted service that signs you in and connects your computers to each other and to your browser. Its terms are the Account Terms. You never need an account to run ToolsEnabled software on your own computer, and the records below are separate from anything that software keeps on your computer.

If you create an account, we keep:

Choose computer and passkey names knowing that we store them.

What the relay sees. Connections between your devices are end-to-end encrypted. When your devices cannot reach each other directly, our relay carries the encrypted traffic; it does not store or read the contents. The account database does not store the contents of any session.

Cookies. The sign-in, sign-up and account pages set cookies that are needed to keep you signed in: a session cookie, and short-lived cookies that hold a Google sign-in while it is in progress. They are not used for advertising or analytics. The rest of this website sets no cookies.

Addresses. The service uses the network address you connect from to apply rate limits and the location restriction in the Account Terms. Our servers' standard access logs also record it.

Security mail. When you ask for an action that needs one, such as adding a computer, setting or resetting a password, first passkey setup, deleting your account or a longer idle time, we email a security code to your account address. We send no marketing mail. That mail is carried by the provider that hosts our mailboxes, which processes the address and message.

Purpose and how long we keep it. We use these records only to sign you in, keep your account secure, add and connect your computers, diagnose connection problems and provide the account controls you ask for. Account records stay while the account exists. Sessions expire or are revoked and are then cleared. A passkey record stays until you remove that passkey or delete the account. Records of removed computers are deleted after 90 days.

Deleting your account. You can delete your account from the account page after a security check; if passkey protection is on, that check needs a passkey. Deletion removes the account, its acceptance, session, passkey and computer records. If you cannot reach your account, write to support@toolsenabled.ai; that is not a way to bypass passkey protection. Backup copies and logs are kept only as long as our hosting and backup practices require.

Where it is kept. These records live on a server we operate at a hosting provider, which processes the stored data. Encryption and access restrictions are safeguards, not a claim that a hosting provider could never access the data. The service is new and has not had an independent security review. The previous version of our account privacy policy (0.9.1-security) stays readable at /legal/privacy/0.9.1-security/.

This website

This website is served from our own server. Apart from the sign-in, sign-up and account pages described under ToolsEnabled account, it sets no cookies. It runs no advertising scripts. Its scripts and graphics libraries are hosted here, not loaded from other sites. Our web server keeps standard access logs (the address that asked, the page and the time) to keep the site secure and working.

Links in our business outreach emails may contain a random campaign identifier. On the website-services and bill-entry pages, our own measurement script records link requests, visible page visits and clicks on the email contact button against that identifier. Our private campaign records connect the identifier to the message we sent. The event store keeps the event type, time, count and whether the request resembles known automation; it does not store an IP address, full browser identifier, cookies or cross-site browsing history. Event records expire after 90 days. Standard server logs for landing pages may contain the campaign URL.

We do not use email-open pixels, Google Analytics or third-party advertising trackers for these campaigns. Link requests and browser events do not prove that a person read an email, wrote a reply or made a purchase. We record replies and sales separately from their actual evidence. You can reply to an outreach email to opt out, or contact josh@toolsenabled.ai about campaign data.

Engine Bench

Engine Bench at toolsenabled.ai/bench runs in your browser. If you enter API keys there, your browser sends each key only to its own AI provider. That includes, for example, OpenRouter, Google, xAI, Mistral, DeepSeek, Anthropic and OpenAI. Your keys are never sent to ToolsEnabled. They are not stored unless you tick "Remember my keys". Then they stay in your browser's local storage until you click "Forget my keys". Your requests to a provider are covered by that provider's own terms and privacy policy. A run record you download stays on your computer unless you choose to share it. Run records hold no keys and no model text.

Head Gasket Bench

Head Gasket Bench, described at toolsenabled.ai/headgasket, runs on your own computer. Its environment makes no network connection of any kind: no telemetry, no update check, no model call and no upload. A run writes its record into the one folder you name with --out: run.json, actions.jsonl, report.json, finish-record.json and launch.json, and an interrupted write can leave a temporary .tmp copy of one of them. The launcher creates a new folder readable only by you, and refuses a folder that is a link or holds links, that belongs to another user or that other users can write to: the environment writes its files by name, so someone who could write to the folder could plant a link there during the run and have the record written elsewhere. A folder your group can write to is accepted, so keep --out where only you can write. A start that makes no tool call records nothing; if a client kills the server before it can clean up (a client that starts the server directly and then signals it), an empty actions.jsonl and possibly a record with no actions are left, and they hold no tool arguments. The next start in that folder clears them. The files hold the tool arguments your MCP client sent, exactly as it sent them, and repeat them in refusal messages and in the mistake events of report.json: if your client puts a user name, a home path, an e-mail address or a host name into an argument, it is in those files. Apart from tool arguments, the environment writes no usernames, home paths, hostnames or environment variables. Your MCP client talks to its own AI provider under your own keys or subscription, and that provider's terms and privacy policy apply. Nothing from a run is sent to ToolsEnabled. A record reaches ToolsEnabled only if you submit it, and a submission is a public pull request on GitHub: anyone can read the files it contains, so look at them before you submit.

Questions

Write to support@toolsenabled.ai. The Fleet plugin's own statement is also kept with its source: the plugin's PRIVACY.md on GitHub. So is the Data plugin's: its PRIVACY.md at release 0.8.9.