If you discover a security vulnerability in tracedecay, please report it responsibly:

• Email: enzinol@gmail.com
• GitHub: Open a private security advisory

Please do not open a public issue for security vulnerabilities. We aim to acknowledge reports within 48 hours and provide a fix or mitigation plan within 7 days.

Security fixes ship in the latest published release. Pre-release builds are supported by updating to the latest pre-release; older prereleases and historical major versions do not receive backports. Consult the repository Releases page for the current version rather than assuming a pinned major line remains current.

tracedecay builds a local code graph stored in the active project store. Repo-local projects use .tracedecay/tracedecay.db. Profile-backed projects keep graph data in a private user profile shard such as ~/.tracedecay/projects/<project_id>/, while the repository may contain only an enrollment marker plus project config. The database contains:

• Symbol names, signatures, and docstrings
• File paths, sizes, and content hashes
• Call relationships and dependency edges
• FTS5 search index
• Cross-session memory: durable facts, named entities, code-area notes, decisions, and feedback events in the holographic fact store. Those rows are local-only project data.
• A response cache for mode-aware source reads (read_cache table): the rendered output served to the agent, stored as a BLOB keyed by file path, mode, and arguments. For full/line-range reads this rendered output contains source text. Rows are freshness-gated by file mtime and swept after a period of inactivity.

Sealed code-index artifacts also persist sanitized source chunks for retrieval. Sanitization can remove detected secrets; it does not remove proprietary source or guarantee that all sensitive content is recognized. Treat index artifacts, source-read responses, session messages, and durable facts as private data. Local operation is the default. Explicitly configured remote sources and remote authorities can exchange policy-authorized content with authenticated peers; these deployments require reviewing their configuration and peer trust.

The user-level ~/.tracedecay/global.db tracks indexed projects, aggregate token-savings counts, and cost accounting data parsed from Claude Code session transcripts. Cursor transcript search is stored in the active project's session store (.tracedecay/sessions.db for repo-local projects), which contains ingested Cursor user/assistant message text plus transcript paths and metadata for that project. These stores are local by default; configured remote authority operations follow their explicit admission and disclosure policy.

The MCP process communicates with its host over stdio, but TraceDecay also has explicitly local listeners:

• tracedecay dashboard and the tracedecay_dashboard MCP tool can start an HTTP dashboard on 127.0.0.1, localhost, or [::1]. Requests must carry a loopback Host naming the bound port. Browser requests that include an Origin must use the same dashboard origin. The dashboard has no remote-user authentication and is intended only for a trusted, single-user local environment. HTTP clients cannot enable automation pre-run shell commands; allow_job_commands requires explicit local operator configuration.
• The daemon uses an owner-only Unix socket where supported. Its TCP fallback is restricted to a loopback address and requires the daemon authentication preface. The daemon's application HTTP adapter binds an ephemeral 127.0.0.1 port and requires both its bearer token and exact local origin.

These controls limit network reachability; they do not isolate TraceDecay from other processes running as the same operating-system user.

Outbound capabilities include:

Provider usage and pricing do not add an outbound connection. tracedecay cost reads immutable provider-native usage observations and the deterministic bundled all-provider pricing table, identified by its content digest. Reads are side-effect-free: there is no request-triggered network refresh, home-directory pricing cache, or pricing environment override. Missing, unknown, or unavailable evidence remains typed rather than becoming a zero or a stale estimate. Semantic model downloads use a private TraceDecay cache, verify catalog-pinned lengths and SHA-256 digests before publication, and can be disabled with HF_HUB_OFFLINE.

TraceDecay does not require credentials for its default local and public repository behavior. When GH_TOKEN, a gh login, or a git credential helper login for https://github.com exists, GitHub reads for the checkout's origin use it; the token is read into zeroizing memory per use and never stored. The git credential helper is asked only for protocol=https/host=github.com, with terminal prompts disabled. A user may explicitly configure a private GitHub review source with access = "os_keyring" and keyring service/account locators. The secret remains in the operating-system keyring; configuration stores only its locator. The daemon reads it into zeroizing memory, sends it only to GitHub over HTTPS, and mounts the source only after verifying an exact read-only permission set. Missing, ambiguous, write-capable, or unverifiable credentials fail closed.

The MCP server exposes more than 70 tools. The large majority are read-only analysis and query operations marked readOnlyHint: true. A small set mutate local state and are marked readOnlyHint: false:

File-editing tools (modify source files in your project):

• tracedecay_str_replace, tracedecay_multi_str_replace, anchored string replacement
• tracedecay_insert_at, tracedecay_insert_at_symbol, anchored insertion
• tracedecay_replace_symbol, replace a symbol's body
• tracedecay_ast_grep_rewrite, structural rewrite via the in-process ast-grep engine

Local-state tools (write only inside the active TraceDecay store, never your source):

• tracedecay_fact_store_add, tracedecay_fact_store_update, tracedecay_fact_store_remove, tracedecay_fact_store_supersede, and tracedecay_fact_feedback, store, remove, or supersede fact text, entity names, feedback events, and trust-score inputs in the local project database. The other exact tracedecay_fact_store_* routes and tracedecay_memory_status are read-only; repair is daemon-owned background work.

Storage status, doctor, quota, and support-bundle output must report the active project, store class (project_local, profile_sharded, or global/accounting), and final-shape admission state without exposing sensitive payloads by default. A redacted support bundle may include aggregate counts, lock/dirty/quota state, and error codes; it must exclude source code, rendered read_cache bodies, transcript text, memory fact content, payload bodies, and response-handle bodies.

Also redact credential-bearing git remotes, database overrides such as TRACEDECAY_GLOBAL_DB, private adapter config paths, response-handle identifiers that could retrieve plaintext, and error strings that embed local paths or secrets. Full paths or payload excerpts require an explicit opt-in flag and sensitive labeling. See docs/PROFILE-STORAGE-SUPPORT.md for the support-bundle privacy boundary, and the V2 operating model for final storage authority and reset behavior.

Test execution:

• tracedecay_run_affected_tests, compiles and runs the project's own test suite via a cargo subprocess (bounded by a configurable wall-clock timeout, default 300 s, and a per-invocation test cap)

The edit tools target a single file with a unique anchor and re-index in place. They never run shell commands you did not supply. Network-capable operations are limited to the documented release, pricing, semantic-model, telemetry, and configured GitHub review paths above. Every editing and state-mutating tool is single-file or single-record scoped. There is no bulk-delete or recursive-write primitive.

Note: file edits are applied by the agent on your behalf through your agent's own tool-approval flow. Treat tracedecay's edit tools with the same caution as your agent's built-in file-write tools.

tracedecay upgrade downloads pre-built binaries from GitHub Releases. The upgrade process:

• Downloads from the same release channel (stable/beta) currently installed
• Replaces the running binary in place via self-replace
• Re-registers agent integrations on the next launch when the version bump is minor or major

Installer provenance: install.sh checks same-release SHA-256 sums and uses gh attestation verify to verify build provenance against the configured release workflow. Missing verification fails installation unless the operator explicitly opts into the documented unattested install path. Checksums alone establish consistency, not independent publisher authenticity. Other distribution/update paths have their own verification; do not assume installer checks apply to all paths.

Windows: Authenticode code signing via the SignPath.io Foundation program is being rolled out so Windows binaries are signed as part of the release workflow (addresses the Smart App Control block reported in #79). Until that lands in a published release, Windows binaries remain unsigned.

tracedecay installs no background daemon, system service, or autostart process by default. Users can explicitly opt in with tracedecay daemon install-service, which installs a per-user systemd service on Linux or a per-user LaunchAgent on macOS. The daemon runs with standard user privileges and never requests elevation. Index freshness still relies on on-demand staleness checks, catch-up syncs when MCP clients connect, and bounded hook notifications; the daemon provides shared MCP process/socket reuse and scheduled automation for projects that connect to it.

Unsafe Rust and FFI exist in several owners, including private filesystem identity/platform primitives (crates/tracedecay-private-fs), tree-sitter grammar bindings (crates/tracedecay-code-extraction/src/ts_provider.rs), and platform runtime integrations. This is not an exhaustive inventory. Review the relevant platform implementation and its invariants when changing those boundaries; an old count of unsafe sites is not a security guarantee.

• Add .tracedecay/ to your .gitignore to avoid committing local store markers or repo-local databases.
• If your project contains sensitive code, be aware that the database stores symbol names and signatures, and the read_cache table can hold rendered source text from source-read responses. Keeping repo-local store directories ignored and treating profile-sharded stores as private user data keeps both out of version control.
• Keep tracedecay updated (tracedecay upgrade) to receive security fixes.
• Review the CHANGELOG before upgrading to understand what changed.

The following are not security issues:

• The aggregate token counter sending a count to the public Cloudflare Worker endpoint (this is documented behavior and contains no identifying information beyond an approximate country derived from IP by Cloudflare)
• The database containing symbol names or file paths from your project (this is core functionality)
• The MCP edit tools modifying files (this is opt-in functionality your AI agent invokes through its own tool-approval flow)
• tracedecay_run_affected_tests compiling and running your project's own test suite (this is the tool's documented purpose)