PRIVACY.md

CoalBoard Privacy Policy

CoalBoard collects nothing and phones nowhere.

• No telemetry. No usage data, analytics, or identifiers are collected, stored, or transmitted — by the skill, the conductor hook, or any bundled component.
• No network calls from the hook. The conductor hook is offline by design (Phoenix Commandment #7): it reads the prompt and .coalboard.json locally and emits an advisory directive. It opens no sockets and makes no requests. (The self-update check is the agent's /coalboard:update procedure, run only with your consent — never the hook.)
• Reads for the data lens go out from your agent, not from CoalBoard. For a code, CI or config target the board may read public advisory and documentation pages and the target's own alert lists (fields only; the secret-scanning request asks GitHub not to return the value (hide_secret=true), and a response that still carries one is discarded unread and reported NOT-CHECKED) with whatever read access your environment already offers; it never asks for, stores or prints a credential. CoalBoard sends nothing of its own.
• The board runs inside YOUR agent. CoalBoard operates no servers and receives no traffic. When it convenes, it spawns lens workers through your agent's own native subagent tool, on your account, under your platform's permission gate — CoalBoard calls no model API itself and does not bypass that gate.
• Propose, never execute. The board writes proposals to a local .coalboard/proposed/ staging directory; nothing touches your live files or fires a side-effect until you approve. Credential patterns are scrubbed from anything logged or displayed on a best-effort, contract-enforced basis — the agent applies the scrub mandate from the skill contract at runtime; there is no shipped scrub() function (scripts/lib/secrets.mjs is the DEV reference implementation + test target, not in the plugin runtime). Defense-in-depth, never a guarantee a secret is caught — the real protection is staging + the propose-not-execute contract + each seat's least-privilege grant: leaf-ness (no seat ever holds a write or spawn tool) is platform-enforced, while a seat's run/fetch right is contract-strength on Claude Code, never a platform restriction (see Permissions in the README for the per-seat grants).
• Error reports are manual. When a component misbehaves, your agent may offer to open a pre-filled GitHub issue; nothing is submitted automatically, and you see and edit the full contents first.
• Local files only. All state lives in files you can read: the config (~/.claude/.coalboard.json, and an optional per-project config found in order — the executing agent's own dir first, then the fixed fallback .claude/coal/coalboard.json → .agents/coal/coalboard.json → .gemini/coal/coalboard.json → the two deprecated legacy shapes .claude/.coalboard.json then .coalboard.json, still read for an existing project (full order and the deprecation note in README Configure); the global ~/.claude/.coalboard.json is not deprecated) and the project-scoped .coalboard/ staging directory (proposed/ = staged changes awaiting your approval · reports/ = audit reports & post-mortems · memory/ = a worker's private resume checkpoint, run-scoped and deleted at the end of every run). A run that executes a command against your target also makes a lab clone of the files it needs, outside your home tree (its real path is checked before anything is copied; a TMPDIR inside the home tree falls back to /tmp, or the run says why; recommended: %ProgramData%\CoalBoard\lab\<run-id> on Windows, mktemp -d under TMPDIR or /tmp on POSIX); beside the clone sits the S2 backup of your real configs, and on Windows the run directory is restricted to the current user; every run removes the whole run directory, backup included, when it ends and says so in its return; a real file the run changed is restored from the backup, and its post-run version is first saved into a private folder, <run-id>.post-run/, beside the run directory under the lab root (outside your project, restricted to your user (icacls on Windows, mode 0700 on POSIX), copies named by SHA-256 with a manifest.txt); that folder may hold a secret, is kept after the run for you to reconcile and delete, and the report names only its path (references/run-safety.md S2, S3, S5). The installed skill's own runtime writes into exactly one of these: answering "always, this project" at the Fable money gate persists that one key (fableConsent: "always") into your project config (the read order above — own-dir default if none exists yet, moving a legacy file there in the same write) — no other key, and never the global config. Also stored: the self-update throttle stamp ~/.claude/coal/coalboard/update-check (a timestamp, nothing more). A repo checkout adds one more writer, outside the installed skill: scripts/configure.mjs (scripts/ is not in build-plugin.mjs's copy list, so it never enters plugin/ and an installed-only user never receives it) writes whichever key you pass it to the project config, or — with --global — to ~/.claude/.coalboard.json, the global layer (when it migrates a legacy-location config it removes the legacy file it moved when git answers that the file is not tracked, or when no repository surrounds it (if git tracks it, or cannot say, for example with no git on PATH, inside a repository, it keeps the file and prints why), it refuses to write, and makes no folder outside the project, when a link or junction sits on the path to the project config folder or the config file itself is a symlink, and when the config it reads is malformed it first saves a copy beside it as <config>.bak); you invoke it explicitly, it is not something the board runs on your behalf.

Questions: open an issue at https://github.com/TheColliery/CoalBoard/issues.