Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.entire.io/llms.txt

Use this file to discover all available pages before exploring further.

Entire stores AI session transcripts as Git data alongside your code. Secret detection is built on Betterleaks, with additional Entire-specific layers for high-entropy strings, credentialed URIs, database connection strings, and opt-in PII. This page explains what’s stored, how secrets and PII are redacted before storage, when data leaves your machine, how commits are signed, and how to report security issues.

​
Where your data lives

Transcripts and checkpoint metadata go to a dedicated branch in your Git repository (entire/checkpoints/v1), not to a service Entire controls. The web app at entire.io reads from that branch — what users see in the web app is the already-redacted content from the branch. Anyone with access to your repository can view the transcript branch. If your repository is public, that branch is public.
Redaction is best-effort, not a guarantee. For sensitive workloads — customer data, internal credentials, regulated material — use a private repository.

​
Reporting a vulnerability

Please do not open a public GitHub issue for a security vulnerability.

Email [email protected]

Report security vulnerabilities directly. We acknowledge within 48 hours and aim to resolve criticals within 90 days. Full disclosure policy below.
The entire/checkpoints/v1 branch is the permanent home for redacted transcripts and checkpoint metadata. It’s pushed alongside your code with normal git push. Anyone with access to your repository can read it.Shadow branches (entire/<short-hash>) hold working snapshots during a live session. Metadata (transcripts, prompts, incremental checkpoint data, subagent transcripts) is redacted on write. Code-file snapshots, however, are raw blobs of your working tree without redaction — so any hardcoded secrets in your source files appear unredacted on the shadow branch. Gitignored files (e.g. .env) are filtered out of those snapshots as a partial defense. Shadow branches are local-only and are not pushed by Entire; do not push them manually, because unredacted source content would land on the remote.Two redaction passes for metadata. Metadata is redacted on shadow-branch writes and again at condensation time when data is rolled into entire/checkpoints/v1. The metadata that lands in checkpoint storage — local or pushed — has been through redaction; the entire/checkpoints/v1 branch contains only metadata, no source code.RedactedBytes type guarantee. Internally, the redact package exposes a typed wrapper that compile-time enforces redaction has happened before checkpoint writes — accidental writes of un-redacted data are caught at the type level rather than at runtime.Commit trailers. Commits on your normal branches gain Entire-Checkpoint: <12-char-hex> and Entire-Attribution: <percent> agent (<n>/<m> lines) trailers. The trailers are public on push and live forever in commit messages. The hex is a random ID with no embedded PII; the attribution counts are aggregate numbers (no per-line content).Remote URL redaction in logs. When a fetch or push fails, error messages and .entire/logs/ entries strip passwords from URLs (e.g. https://user:****@github.com) so credentials don’t end up in local log files.
Five layered detection passes run during condensation. Anything matched by any layer is replaced with the literal token REDACTED. The pipeline cannot be disabled.
  1. Entropy scoring. Strings of 10+ alphanumeric characters with Shannon entropy above 4.5 are flagged. Catches API keys and tokens that don’t match any known vendor pattern.
  2. Pattern matching via Betterleaks. The CLI embeds the Betterleaks detector, which ships ~260+ rules covering cloud providers (AWS, GCP, Azure), version-control platforms (GitHub, GitLab, Bitbucket), payment processors (Stripe, Square), communication tools (Slack, Discord, Twilio), private-key blocks (RSA, DSA, EC, PGP, OpenSSH), and generic credentials (bearer tokens, basic auth, JWTs).
  3. Credentialed URI detection. URLs that embed user:password@host — for example postgres://user:pass@host/db or redis://:pass@host/0 — are redacted as a unit. These often have moderate entropy and aren’t reliably caught by vendor-specific patterns.
  4. Database connection-string detection. Four sub-patterns: JDBC URIs (jdbc:...), database URLs (Postgres, MySQL, MariaDB, MongoDB, Redis), Postgres-style keyword DSNs (host=... user=... password=...), and SQL-Server-style semicolon connection strings (Server=...;User Id=...;Password=...). When a real (non-placeholder) password is present, the entire connection string is redacted because partial fragments can still expose sensitive material.
  5. Bounded credential value detection. Variable assignments where the key matches a known credential name (DB_PASSWORD, PGPASSWORD, MYSQL_PWD, REDIS_PASSWORD, MONGO_PASSWORD, MONGODB_PASSWORD). Inside JSON, generic password/passwd/pwd keys are also redacted when the surrounding object looks like a connection descriptor — i.e. it contains both a host-like field (host/hostname/server/addr/address/datasource) and a user-like field (user/username/userid/uid). Only the value is redacted; the key is preserved.
False-positive handling:
  • JSON fields named signature are skipped entirely.
  • JSON keys ending in id or ids are skipped (these are typically opaque identifiers).
  • JSON keys for structural paths (filepath, file_path, cwd, root, directory, dir, path) are skipped.
  • JSON objects with type starting with image or equal to base64 are skipped (image and base64-encoded payloads are not scanned).
  • Placeholder values are not redacted. Detected by exact match (changeme, example, placeholder, your_password, your_db_password, your_secret, secret_here, plus prior REDACTED/[REDACTED]/<REDACTED> markers) or by shape: shell expansions like ${DB_PASSWORD}, bracketed names like <password> or <your-db-password>, and mask runs of three or more *, x, ., or - (so ***, xxxx, ...., ---- all match).
  • Connection strings whose passwords are placeholders (e.g. ${DB_PASSWORD}) are left intact.
PII redaction is a separate, opt-in layer that runs in addition to secret redaction. Disabled by default. Configured under redaction.pii in .entire/settings.json (team-shared) or .entire/settings.local.json (personal, gitignored).Built-in categories:
CategoryDefault when PII is enabledReplacement token
emailOn[REDACTED_EMAIL]
phoneOn[REDACTED_PHONE]
address (US street addresses)Off (more false-positive prone)[REDACTED_ADDRESS]
Email allowlist. These addresses are not redacted as PII because they’re public bot/CI metadata that appear in nearly every git transcript: noreply@*, actions@*, *@users.noreply.github.com, *@noreply.github.com.Custom patterns. Teams can add their own regex patterns via custom_patterns. The label becomes part of the replacement token (uppercased). For example, {"employee_id": "EMP-\\d{6}"} produces [REDACTED_EMPLOYEE_ID].Settings example:
{
  "redaction": {
    "pii": {
      "enabled": true,
      "email": true,
      "phone": true,
      "address": false,
      "custom_patterns": {
        "employee_id": "EMP-\\d{6}"
      }
    }
  }
}
Where to put custom patterns. Patterns added under redaction.pii.custom_patterns in .entire/settings.json are committed to the repo and shared with the team — useful for org-wide rules, but the regex itself becomes public if the repo is public. For patterns that themselves shouldn’t leak (e.g. a regex that reveals an internal ID format), add them to .entire/settings.local.json (gitignored, personal) instead.
  • Best-effort. Novel or low-entropy secrets (short passwords, predictable tokens) may not be caught.
  • Filenames and binary data. Secrets in filenames, binary files, or deeply nested structures may not be detected.
  • Skip rules can hide secrets. The structural-field and image/base64 skip rules trade detection coverage for false-positive avoidance — a secret embedded in a path field or a base64 blob will not be redacted.
  • Custom patterns are user-authored. Teams own the correctness of their custom_patterns. An invalid regex is logged and skipped, not enforced.
  • Users are ultimately responsible for reviewing what they push. Redaction is a safety net, not a guarantee.
  • Use a private repository for sensitive workloads. Simplest and most complete protection.
  • Avoid passing sensitive files into agent context. Content that never enters a transcript can never be exposed by transcript redaction failure.
  • Review the entire/checkpoints/v1 branch locally before the first push. Same review you’d do for any other branch going public.
  • Enable PII redaction if your team works with customer data. It’s off by default; turn it on per-repo or globally with the settings example above.
The CLI captures anonymous usage analytics by default. Sent to PostHog at eu.i.posthog.com. Event name: cli_command_executed.What’s captured per command:
  • Command name (e.g. entire enable, entire checkpoint rewind)
  • Selected agent name (or auto)
  • Whether Entire is enabled in the current repo
  • CLI version
  • OS and architecture (e.g. darwin/arm64)
  • Names of flags passed (not their values)
What’s not captured: flag values, prompt text, transcripts, file paths, repository identifiers, GitHub usernames, source code, IP-derived location (the PostHog client is configured with DisableGeoIP: true).DistinctID is a hashed machine identifier derived from machineid.ProtectedID — stable per machine, not directly mappable to a person.Opt out (any one of):
  • Pass --telemetry=false on commands that accept it.
  • Set "telemetry": false in .entire/settings.json or .entire/settings.local.json.
  • Set the env var ENTIRE_TELEMETRY_OPTOUT=1.
The first run of entire enable or entire configure asks for telemetry consent interactively; declining there sets the setting to false.
The CLI runs locally and talks to external services in only a few specific cases:
WhenWhereWhat’s sentRedacted?
git push of an Entire-enabled branchYour Git remote (e.g. GitHub)Already-redacted contents of entire/checkpoints/v1 plus your codeYes — redaction has happened by the time it’s on the branch
entire checkpoint explain --generate (on-demand AI summary)Whichever provider is configured via summary_generation.provider — typically the same agent that ran the session, e.g. Claude (Anthropic), Codex (OpenAI), or Gemini (Google)Compacted transcript for the checkpoint being summarizedYes — redact.JSONLBytes runs before the transcript is handed to the summary provider
Telemetry (unless opted out)PostHog at eu.i.posthog.comCommand name, agent, flags-by-name, OS/arch, machine hashN/A — no transcript or code data sent
GitHub auth (during entire enable flows that touch GitHub)GitHubDelegated to the gh CLI; Entire does not store its own credentialsN/A
Checkpoint remote (optional, opt-in --checkpoint-remote)The configured separate Git remoteRedacted checkpoint branch onlyYes
External agent plugins. Plugins are arbitrary executables on $PATH that the CLI invokes during agent sessions. They have the same filesystem access as the CLI itself. Only install plugins you trust. See External Agent Plugins for the protocol; the security warning there applies fully.
Checkpoint commits (on the shadow branch and the metadata branch) can be GPG- or SSH-signed using the same key already configured for your regular Git commits.Requirements (all of these must be true):
  1. commit.gpgsign = true is set in your global or system Git config.
  2. A supported signer is available — GPG (default) or SSH (set gpg.format = ssh and run ssh-agent).
  3. The Entire setting sign_checkpoint_commits is true (the default; defaults to true when unset).
Best-effort behavior. Signing never blocks a commit. If the signer is unavailable, fails, or your hardware token requires a touch you didn’t give, the commit is created unsigned and a warning is logged to .entire/logs/. This avoids data loss in CI environments and during automated checkpoint saves.Opt out by setting "sign_checkpoint_commits": false in .entire/settings.json (team-shared) or .entire/settings.local.json (personal). Opting out does not affect signing of your regular commits.
Reporting. Email [email protected]. Do not open a public GitHub issue for a security vulnerability.Include in your report:
  • A clear description of the vulnerability.
  • The impact (what an attacker could achieve).
  • Detailed steps to reproduce.
  • Affected CLI versions if known.
  • A suggested fix if you have one (optional).
What to expect:
  • Acknowledgment of receipt within 48 hours.
  • Progress updates as we investigate.
  • Resolution within 90 days for critical vulnerabilities.
Confidentiality. All reports are kept confidential. We will not share your information with third parties without your consent except as required by law.Scope. The CLI (entire), official Entire GitHub repositories, and entire.io services.Out of scope (report upstream / treat as bug reports):
  • Issues in third-party dependencies.
  • Social engineering attacks.
  • Denial of service that requires local access to trigger.
  • Issues that cannot be exploited without direct access to the user’s machine.
Bug reports vs security advisories. Security advisories are reserved for confirmed vulnerabilities exploitable by a remote or non-local actor. Because the CLI is primarily a local development tool, the following are tracked as bug reports rather than advisories: regular-expression performance issues (ReDoS) on local execution, resource exhaustion that requires local access to trigger, and issues that cannot be exploited without direct machine access. File those at github.com/entireio/cli/issues.