Security: what Treelab protects, and what it does not claim to protect

Guardrails: operations refused by default

Before each command of the agent, Treelab’s hook reads what it is about to run. Common destructive operations are refused by default: git reset --hard, git clean -f, a forced push to or deletion of a protected branch, rm -rf outside the worktree, a commit on the main branch from the main checkout, and a raw deployment when the project declares its deployment target.

Each refusal names the safe alternative, which the agent then takes. The same hooks serve Claude Code and Codex; Codex asks you to approve them once through /hooks, and lab doctor checks that they are active.

✗git reset --hardLAB: git reset --hard refused: it erases uncommitted work (yours or another session's). Alternative: a WIP commit, or a targeted git restore <file>. If the user explicitly asked for it, run it again with LAB_FORCE=1 before the command.✗git push --force origin mainLAB: git push --force (or refspec "+…", --mirror) to "main" refused: it rewrites the shared history and erases the commits merged by the other lanes. Alternative: push a batch branch (git push -u origin <branch>) and open a PR. LAB_FORCE does not lift it: ask the user to do it themselves if they really want it.✗rm -rf ../../project-2LAB: rm -rf "../../project-2" refused: outside the current worktree (or target not resolvable). Alternative: trash <path>, or an explicit path under the worktree. If the user explicitly asked for it, run it again with LAB_FORCE=1 before the command.

What the guardrails are not

It is a closed list of common operations, not a sandbox. The guardrails do not confine the agent, do not filter the network and do not replace your tool’s permissions: those of Claude Code or Codex remain yours, set by you.

A hook never blocks the work by accident: on an internal error, it lets the command through silently rather than freeze your session. That is a deliberate choice. The guardrails prevent common mistakes; they are not an exhaustive security boundary.

The data that leaves your Mac

Treelab sends no telemetry: no usage measurement, no tracking of your commands. Only three moments contact treelab.sh; the other exchanges go to your own remote repositories, through git and the GitHub CLI, when lab merge, lab close or lab sync deliver or synchronise your work.

The installer, at purchase then activation: it sends your licence key and a random identifier for this Mac, machine_id, which allows one activation at a time and its transfer to another machine.

lab update and the automatic update of lab next: they send your licence and the same identifier, to download the version. The archive and its fingerprint are checked before switching, and the previous version is kept.

Everything else stays on your computer: your repositories, documents, logs and evidence stay with you and in your own remote repositories. The legal detail is in the privacy policy.

This site

treelab.sh loads no audience measurement or advertising tool, and no third-party font or script: its content security policy only allows its own files. The only storage is your language choice, kept for the session. The site never asks for your licence key.

Share a diagnostic without leaks

lab doctor --report prepares an anonymised diagnostic of your installation without sending it: you read it, then decide whether to attach it to a message to support.

Report a vulnerability

If you believe you have found a vulnerability in Treelab, on this site or in the activation service, write to the address given in our security.txt file. Describe the problem, how to reproduce it and its impact; do not attach a licence key, a secret or confidential code.

Please give us time to fix the problem before making it public.