feat(mcp): add telemetry enable/disable CLI command with persisted opt-in

[nghetienhiep]

feat(mcp): add telemetry enable/disable CLI command with persisted opt-in

Local MCP usage telemetry is opt-in and defaults OFF (per #6228's privacy
decision). Add a telemetry enable/disable/status command that persists a
top-level telemetryEnabled flag in the same config file login uses, so the
choice survives across CLI invocations. status, doctor, and config now
report the current opt-in state, and every subcommand supports --json.

Disabling on an otherwise-empty config removes the file rather than persisting
telemetryEnabled: false, and only a literal true in the config counts as an
opt-in so a malformed value falls back to the privacy-preserving default.

Closes #6239

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-16 03:30:20 UTC}

4 files · 1 AI reviewer · no blockers · readiness 95/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This adds a `telemetry enable|disable|status` CLI command that persists a top-level `telemetryEnabled` flag via the existing config file, wires the state into `status`, `doctor`, and `config` output, and closes #6239 per the #6228 privacy decision (opt-in, default off). The persistence logic correctly mirrors login/logout: `setTelemetryEnabled` strips the key unless it's exactly `true` (via `normalizeConfig`), `hasPersistedConfigState` now accounts for the flag so an otherwise-empty config is removed on disable, and only a literal boolean `true` from disk counts as opt-in, guarding against malformed/legacy values. The test suite exercises the default-off state, persistence across invocations, doctor/status/config surfacing, coexistence with an authenticated profile, and the malformed-value fallback — a solid, well-targeted change tied to a real issue.

Nits — 5 non-blocking

• packages/loopover-mcp/bin/loopover-mcp.js: `telemetryCommand` doesn't validate `--json` combined with `help`/`--help`, so `telemetry help --json` silently ignores `--json` and prints plain-text help — minor inconsistency with other subcommands.
• packages/loopover-mcp/bin/loopover-mcp.js:3705 `setTelemetryEnabled` always calls `normalizeConfig` even when the enabled state is unchanged from the current config, causing an unnecessary write path check (`hasPersistedConfigState`) to run every time — harmless but slightly redundant.
• The `telemetryState()` function's `default: false` field is static and never varies, so it's effectively dead weight in the returned object unless future code paths intend to make it configurable — consider dropping it or documenting its purpose.
• Consider validating `subcommand` against the `CLI_COMMAND_SPEC.telemetry` list directly in `telemetryCommand` rather than hardcoding the error message string, so the spec and error stay in sync automatically.
• README's new 'Telemetry opt-in' section could mention what data is/would be collected (or link to where that's documented) since the opt-in framing currently only covers the toggle mechanics, not the substance.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#6239
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (1 linked issue).
Validation posture	⚠️ 20/25	Preflight is ready, but the PR body does not name the validation run.
Contributor workload	✅ 10/10	Author activity: 126 registered-repo PR(s), 73 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	nghetienhiep; Gittensor profile; 126 PR(s), 0 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
The PR adds a telemetry enable/disable/status command group persisted via a top-level telemetryEnabled flag in the same config file used by login, surfaces the state in status/doctor/config, supports --json across the new subcommands, and includes tests covering toggling, default-off state, and config persistence.

Review context

• Author: nghetienhiep
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 126 PR(s), 0 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Add validation command/output.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://gittensory.aethereal.dev/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[loopover-orb]

LoopOver approves — the gate is satisfied and CI is green.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.60%. Comparing base (905543d) to head (55217e4).
⚠️ Report is 26 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6348   +/-   ##
=======================================
  Coverage   95.60%   95.60%           
=======================================
  Files         597      597           
  Lines       47191    47191           
  Branches    15019    15019           
=======================================
  Hits        45117    45117           
  Misses       1290     1290           
  Partials      784      784           

Flag	Coverage Δ
shard-1	44.15% <ø> (ø)
shard-2	36.52% <ø> (+0.12%)	⬆️
shard-3	32.54% <ø> (+<0.01%)	⬆️
shard-4	34.68% <ø> (-0.18%)	⬇️
shard-5	31.57% <ø> (ø)
shard-6	44.87% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.