In the project’s gitignored .trigger-tree/history.jsonl and rotated archives.
Injected guidance is loaded without a Read tool call. It is classified as always loaded rather than misrepresented as cold.
It cannot prove understanding or causation. It can measure a narrower question: when a
user-confirmed directive probe applied, did the local event stream observe the requested
behavior? /tt instructions --init creates the committed manifest scaffold and
/tt instructions reports followed, unobserved, never-triggered,
awaiting-capture, no-violations-observed, unobservable, and capture-disabled
directives. Unobserved never means violated. See
instruction adherence.
Can it tell me which agent personas I actually use?
Yes, once TT_LOG_AGENTS=on (written by /tt setup). Only the persona name of a launched
subagent is recorded, never the task given to it. /tt insights reports invocations per
persona and which definitions have never been invoked. A definition's description is in
the system prompt on every request, so an unused persona is recurring cost in the same way
an untriggered directive is. Never-invoked is a review prompt, not a removal
recommendation, and it is withheld entirely until agent capture has actually run.
Untouched is a review signal. Check whether it is protected or missing from its folder router; the right fix may be a link, not deletion.
Reload plugins and confirm the running version. A current-version crash keeps the pane open with its error.
Sandboxed application runtimes (Codex Desktop and similar) have no GUI session
for AppleScript, so no terminal window can be opened from there — running the
same launcher from a real terminal works. The launcher detects this and prints
the exact tt-watch.py command to paste into a second terminal.
Ensure python3 resolves on PATH. Claude’s documented exec-form hooks do not provide an operating-system condition.
Yes. Before a project runs setup only hashes are stored — hooks are user-wide,
and other repositories have not consented yet. Prefer no linkable hashes at all
before setup? Set TT_LOG_PROMPTS='off' in the user-wide
~/.trigger-tree/config.sh: it applies to every repository, and tt doctor
reports the effective mode with the layer that selected it. /tt setup asks per
project for truncate (a local, gitignored preview of at most 200 characters),
hash, or off; the project choice wins over the user default, and changing
the mode affects future events without rewriting history.
Topic labels for adherence are separate. Existing installs default
TT_LOG_TOPICS, TT_LOG_COMMANDS, and edit capture to off; setup explains and writes
each choice explicitly. Topic labels come only from the repository's bounded vocabulary
and never contain prompt-derived free text.
/tt uninstall removes trigger-tree wiring but deliberately preserves local telemetry
and ignore entries for you to delete explicitly. make badge-publish publishes only the
aggregate local docs-health endpoint to an existing badges branch; it never publishes
paths or event history.
Yes: add the marketplace from a git ref and install from that snapshot —
codex plugin marketplace add Hedde/trigger_tree --ref vX.Y.Z
codex plugin add trigger-tree@trigger-tree
Without --ref, marketplace installs follow the repository default branch. The
GitHub Action (uses: Hedde/trigger_tree@vX.Y.Z) and
pip install trigger-tree==X.Y.Z pin the same way.
Codex runs plugin hooks only after you trust them, and it skips untrusted hooks
silently. Start the interactive TUI, review the Hooks need review prompt for
the four trigger-tree hooks, and choose Trust all and continue. Two things
are easy to miss: non-interactive codex exec runs never persist trust, and an
upgrade that changes a hook resets its trust, so the review comes back. tt doctor reports the persisted trust state whenever a Codex install is present.