Trust from accuracy, not adjectives.

While a session runs, Cockpit's hooks see the events Claude Code raises. From them it reads:

• Prompts you submit. The first 160 characters of a prompt, on one line, become the working title of an unplanned task and the "latest prompt" of the current one. The full prompt is not copied.
• Tool calls. The tool's name, its id, how long it took, whether it failed, and a file path where the call has one. For Edit and Write, the text before and after the change is read for the replay snapshot. A shell command is read to classify it and to check it against the blast-radius and attribution guards. The HUD's current-activity line holds a short label for the call in flight: a file's base name, a search pattern, a web host, or the first 40 characters of a shell command, a search query or a subagent's description.
• Subagents. Their ids, types, the short description on the call that started them, requested and observed model names and reasoning levels, status and counts, and the first 160 characters of a subagent's final answer, kept as that agent's conclusion.
• Orchestration assignments, when the model uses the swarm tool: each task's objective, scope, dependencies, the paths it owns, its results and handoffs.
• Progress reports, when the model uses the progress tool: the goal, milestone titles and notes, gate states and the one-line evidence given for each.
• Model requests. The model and reasoning level requested and observed, and token counts (input, output, cache read, cache write) where Claude Code reports them. Not the content of a request or a response.
• Context usage: tokens used, window size and percent, from Claude Code's own meter.
• Git state: branch name, HEAD and starting commit ids, the repository's folder name, and counts of changed files, from git status and git rev-parse.
• Working-tree fingerprint (v0.5.1): once a goal check is accepted, Cockpit runs git diff <commit> --name-only, git ls-files -o and git hash-object over the changed and untracked files (up to 2000), reduces them in memory to one short hash, and keeps only that hash with the commit id it was measured against, in the task state. From v0.5.2 the same fingerprint is also taken when a prompt starts a task (the task's baseline) and, while the Stop-hook verification guard enforces, at each Stop it checks; it then also covers ignored files and watched paths: their names are listed and their size, inode and timestamps (not contents) are read with git ls-files -o -i, find and stat (up to 100,000 files). File names and contents are read by git for this and are neither stored nor sent anywhere. Since v0.6.4 each path is first inspected with stat (its kind, size, inode and times, no contents): only regular files are read, a symbolic link is measured by its text through readlink, and a FIFO, socket or device by its kind alone.
• Release-review record (v0.5.1): for each release consultation, the commit id it was for, the consultation id, a time and whether it returned (newest 32), in the plugin store, so a restart cannot reset the budget. Commit ids only; no file content.
• Verification-script runs (v0.5.2, only with stopGuard: ENFORCE and a script you enrolled): the script's exit code, how long it ran, a short hash of the working-tree fingerprint before and after it, and the last six lines of its output on one line (600 characters at most, passed through the credential patterns), in the Run Ledger and the plugin store. The script's own files, arguments and environment are not recorded.
• Claude Code's installed-plugin record: /cockpit doctor reads plugins/installed_plugins.json in your Claude Code configuration directory and keeps, in memory and for that command only, the name, version and install path of each Cockpit entry.
• Discovery, criteria and decisions (v0.5.1): the objective, acceptance criteria, unknowns, risks, the evidence the model reports for each criterion, and recorded decisions (problem, choice, alternatives, evidence), each clipped and redacted for credentials on entry. They stay in the task state; the Run Ledger holds a short entry per task (level, counts, alignment state) and the decision records, redacted again on write and on export. Nothing is written to a project and nothing is sent to a model beyond what the model itself wrote.
• Authentication, by kind only. Whether eight authentication-related environment variables are set (never their values), the names of the settings sources that configure authentication, and the credential kind Claude Code reports (bearer, api-key, none or unknown). The handle Claude Code returns is dropped at once.
• Claude Code settings: the configured model and advisor names (to apply the optional Fable and advisor rules), the names of the settings entries that configure authentication, and the saved reasoning level and its cap.

Cockpit does not store the model's hidden reasoning, the main conversation's replies, the content of a model request or response, or the content of files it has no reason to snapshot. Responses pass through one of its hooks on their way to Claude Code and are forwarded unread; only the usage figures and the answering model's name are taken from them. The one piece of model output it keeps is the subagent answer excerpt above.

In the session (Claude Code's memory)#

The current task, the activity tape, the HUD's state, guard findings, policy and orchestration counters, the authentication kind and the newest NobodyWho receipts are kept in Claude Code's session state. That state lasts until the session ends or you run /clear, /resume or /branch. It survives a reload of the plugin. Cockpit does not write it to disk.

The task held here contains the 160-character prompt excerpts described above, so in-session task state can contain your own words.

On disk, first place: Claude Code's plugin store#

Cockpit saves to two places. The first is the key-value store Claude Code gives each plugin, a JSON file of the plugin's own under the plugins/store/ folder of your Claude Code configuration directory (~/.claude by default). The file's name begins with cobalt-cockpit_. The second, with telemetry on (the default), is a directory of Cockpit's own under your state directory, described under Local model telemetry. Apart from those two places Cockpit writes no file: nothing into a project, nothing into Claude Code's settings.

The store holds six kinds of entry:

A Run Ledger contains:

• The session id, and each run's and turn's id, start, end and status.
• Subagents: id, role, the description from the call that started it (cut to 160 characters), models, reasoning levels, status, timings and counts, and for up to 128 finished subagents the 160-character answer excerpt.
• Tool entries: id, tool name, kind, duration, status, the MCP server name for an MCP tool, and a file path where there is one. Shell commands and tool arguments are not ledger fields.
• Requests: model, reasoning level, routing and fallback reasons, and token counts.
• Context-usage readings.
• Replay snapshots: for a successful Edit or Write, the file path and the text before and after. See the limits below.
• Orchestration: each assigned task's objective, scope, dependencies, owned paths, results (including that answer excerpt as the task's conclusion), handoffs and lifecycle events.
• NobodyWho receipts, reduced as described under NobodyWho.
• Opus consultations (SONNET_LED): the ground, and the evidence packet the main session wrote for it (objective, architecture, file locations, alternatives, failures, risk and question), with credential-shaped spans replaced by [redacted] before it is kept or briefed. /ledger export json passes it through the credential patterns again.
• Session router decisions, as described under The session router.
• Warnings Cockpit raised.
• Stop-guard check records (v0.5.2, the same records as stop-checks, kept with their session) and, with guardAlerts on, alert outcomes: kind, task number, time, sent, failed or resolved, the channel name the host reported, a reminder's ordinal and whether a sound or bell was attempted; newest 32. From v0.5.7 each alert record also carries an 8-character occurrence id (a hash of the condition's key and the moment it was first recorded; it carries nothing of either).
• A checkpoint, rewritten when a turn completes, when you run /park or /ledger, and when a session ends: the phase, completed and remaining milestone titles, gate states, the task's explicit goal if a plan named one (a prompt excerpt is not used as the goal), any blocker text, the branch, commit ids, repository folder name, changed-file count and the ids of running background agents.

Treat the store as private. It can contain file paths, branch names, milestone and task wording, and fragments of source code in replay snapshots.

What limits the record#

• A stored ledger is trimmed to 384,000 bytes, oldest detail first. In memory it holds at most 32 runs, 96 finished agents, 512 tool entries, 512 requests, 64 usage readings, 256 receipts and 32 warnings, plus anything still running.
• Replay keeps at most 24 snapshots and 96,000 characters in all. A snapshot's text is left out when the two sides together exceed 12,000 characters, when the file's name looks sensitive (.env, key and credential files, .ssh, .aws and similar), or when the text matches a credential pattern.
• Short labels (subagent descriptions, answer excerpts, checkpoint text) are cut to 160 characters and passed through the same credential patterns; a match is stored as unknown.
• Orchestration text (an assignment's objective, scope, reasons and events, and each field of a result or handoff) is passed through the credential patterns before it is stored: a matching span is replaced with [redacted] and the rest of the text is kept. It is then cut to 1,500 characters, with at most twelve entries in a list. Redaction is a list of shapes, not a proof: a secret in an unusual format, or written in prose, can still be stored, so do not put credentials in task objectives or handoffs.

These filters are heuristics. They recognise common key formats and file names. They are not a guarantee that no secret is ever stored, so do not put credentials in prompts, milestone titles, task objectives or file names.

A hook of Cockpit's that fails is not allowed to let an action through. The engine skips a hook that throws, times out or answers a wrong shape and runs what is beneath it, so every hook that can answer or refuse carries a .catch handler that answers in its place — the tool guard, the agent-offer and agent-spawn guards, the /config row guard, the /model and /advisor guards, the checkpoint commands and /cockpit itself; turn.step is the one exception, below. Each handler judges the event it was given with the hook's own rule, so a failure refuses what the hook would have refused and lets everything else run, and a prompt is dropped only where this plugin's own policy would drop it. claude plugin validate --strict --json reports each hook and whether it has a handler.

turn.step is the exception, and the reason is structural: for a streaming event the handler must itself be a generator. Its pre-decision readings are wrapped instead, so the hook reaches its Fable, subscription and strict-advisor decisions even when a reading beneath it does not answer. Hooks that only observe — /init, /effort, /login, /logout, post-tool readings — forward, because refusing a person's own action over a lost reading is not a guard.

Inside the tool guard the same rule holds one level down: the attribution, instruction-file and destructive-command guards each run under failClosed, and a guard that throws refuses the call it guards, naming the guard, the tool and an allow-listed kind of error and nothing of the command, a path or the error's message. Nothing is retried or approved on the caller's behalf, tools the guard does not cover keep working, and the next call is checked afresh; the operator's own options (blastRadiusGuard, attributionGuard) still decide which guards run. A check that cannot be made is not an answer: an unreadable filesystem does not mean "the instruction file exists", and under subscriptionOnly only a confirmed subscription sign-in passes: an API-style configuration, an unconfirmed sign-in (unverified), a state not yet read and a state that cannot be read are each refused.

Cockpit has no hook on Claude Code's permission check (tool.check) and asks no permission decision of its own. Its guards run earlier, in tool.call, and only ever refuse a call or put a question to you; nothing in the plugin approves one, so your permission rules, your permission mode and the engine's own dialog decide every call that Cockpit lets through.

It is on by default. The telemetry option defaults to true; set it to false and restart Claude Code to stop recording. This is the one thing Cockpit writes outside Claude Code's plugin store.

What is recorded. One line per observed event, every field an enumeration, a boolean or a number, rebuilt from a fixed list of fields both when written and when read, so nothing outside that list can enter a file or be read back from one:

• a model request: the tier (Haiku, Sonnet, Opus, other), whether it was a subagent's, input and output token counts and cache read and write counts when the host reported them, and the subagent prompt-cache policy in force;
• a subagent that ended: its tier, its role as one of seven fixed words or other, whether it succeeded, and its duration;
• a session-router decision: the mode, whether the rules or the router decided, the provider's name, how many requests were made and answered, the outcome and the latency;
• a NobodyWho receipt: the operation (decision or prune), the tier and the latency;
• an Opus consultation: its ground, what happened (refused, admitted, returned, verified), whether it was mandatory, pass or fail, GO or NO-GO for a release, and the latency;
• a finished task: whether Opus took part.

It never stores a prompt, code, diff, file path, command, session id, agent name, model id, credential or any free text, and nothing is sent anywhere.

Where. $XDG_STATE_HOME/cobalt-cockpit/telemetry/ when that variable holds an absolute path, otherwise $HOME/.local/state/cobalt-cockpit/telemetry/. When neither is known nothing is recorded and /cockpit doctor says so. Cockpit creates the cobalt-cockpit directory and the telemetry directory under it with mkdir -p -m 700; a state directory missing above them is created by that same call with the default mode. It creates nothing else.

Files. Each process writes only files of its own, named YYYY-MM-<8 hex id>-<n>.jsonl (the month, a random id chosen when the process first writes, a running number): a segment is rewritten whole, from memory, by its one writer until it holds 64 KiB or the month changes, then sealed and never written again. No file is ever written by two processes, and a torn write can damage at most one segment, whose damaged lines the reader skips and counts. The directory is bounded at 4 MiB and 13 months by the cleanup described under Retention.

Permissions. The plugin API writes a file but has no file-mode argument. Cockpit asks for the modes it wants (mkdir -p -m 700 for the two directories, chmod 600 for each segment after its first write), reads them back with stat, and reports them as verified only when the read-back shows 0700 and 0600; an existing directory is left with the mode it has and reported unverified. Between the host's write and the chmod a new segment briefly carries the host's default mode. /cockpit doctor prints the result. This is a request and a check, not a guarantee.

Who reads it. /cockpit stats 7d|30d|all [--json|--csv] reads the files of the window and prints the figures in your terminal, and /cockpit doctor lists the file count, size and this session's write, failure and cleanup counts. Nothing else reads the files, nothing is added to a model request from them, and nothing is uploaded; the printed output goes into the Claude Code transcript like any command's.

Deleting. Described under Deleting your data: manual removal of the directory, plus the age and size cleanup Cockpit performs. COBALT_TELEMETRY_SEGMENT_BYTES, read only to let a test seal a segment early, can lower the 64 KiB segment size and never raise it.

Use GitHub's private vulnerability reporting for this repository if available. Otherwise contact the repository maintainer through their GitHub profile to arrange a private channel. Do not post secrets, private ledgers or exploit details in a public issue. Include affected version, a minimal synthetic reproduction and expected impact.