Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/commitlore/issues.md or /mcp/commitlore/issues.json, or Pod over MCP.

Reported issues for CommitLore

Pod holds 17 of 50 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to CommitLore.

Most discussed

MCP tools for commitlore vanish mid-session (ToolSearch returns zero results despite server reported connected)

SSOT incident contract

Preserve the incident evidence. Product closure requires that MCP loss is observable and capture correctness continues through the same local CLI core. Do not claim the server can re-register tools inside a host session it does not control.

Summary

During an audit session, all mcp__plugin_commitlore_commitlore__* MCP t

Read the thread · 2026-08-07 · closed · 11 comments

a release reaches the CLI wrapper but not the Claude plugin cache, and four generations run at once

Measured on one machine, 2026-08-14, while preparing 0.9.0.

Four generations of this product were running simultaneously

$ ps -axo pid=,ppid=,args= | grep -i 'commitlore.*mcp'

47260  ~/.local/share/commitlore/v0.8.1/dist/commitlore.mjs
91147  ~/.local/share/commitlore/v0.8.1/dist/commitlore.mjs
79775  ~/.local/share/commitlore/v0.8.1/dist/commitlore.mjs
34918  ~/.claude/plugins/cache/commitlore/commitlore/0.6.0/dist/commitlore.mjs
26878  ~/.claude/plugins/cache/commitlore/commitlore/0.

[Read the thread](https://github.com/MongLong0214/commitlore/issues/660) · 2026-08-14 · closed · 9 comments

### prepare_capture fails with ENOENT on a dev-hash asset root that is never installed

`commitlore_prepare_capture` fails immediately and cannot be used at all:

commitlore: ENOENT: no such file or directory, open '/Users/isaac/.local/share/commitlore/dev-3b70a1bebfb3/spec/SPEC.md'


The whole capture pipeline is unreachable, because `verify_capture` and `stage_capture` both need the nonce `prepare_capture` returns.

## What is on disk

$ ls /Users/isaac/.local/share/commitlore/ codex-plugin.json v0.8.0 v0.8.1 v0.8.2

$ find /Users/isaac/.local/share/commitlore -maxd

Read the thread · 2026-08-13 · closed · 5 comments

commitlore_prepare_capture fails with ENOENT on a 0.6.0 spec path; the Claude plugin cache only has 0.8.0 and the codex cache has 0.8.2

The capture pipeline is unusable through MCP: commitlore_prepare_capture fails immediately, before any draft is written.

What happened

commitlore_prepare_capture(transcript: "<~2.4 KB session note>")
→ commitlore: ENOENT: no such file or directory,
  open '/Users/isaac/.claude/plugins/cache/commitlore/commitlore/0.6.0/spec/SPEC.md'

There is no 0.6.0 anywhere on this machine. What exists:

$ ls -d ~/.claude/plugins/cache/commitlore/commitlore/*/
/Users/isaac/.claude/plugins/ca

[Read the thread](https://github.com/MongLong0214/commitlore/issues/635) · 2026-08-13 · closed · 4 comments

### MCP commitlore_query reports trust:"claim" for a record the CLI reports as trust:"directive"

Same repository, same path, same record, same moment — the MCP surface and the CLI disagree on the trust grade.

This matters because the MCP surface is the one agents read, and CommitLore's own MCP instructions say to treat `directive` as a constraint and `claim` as "a report to weigh, not an order". An agent reading through MCP therefore ignores constraints it should be obeying.

## Reproduction

Repository: a repo with `commitlore.trustedauthor` configured and at least one record authored by 

[Read the thread](https://github.com/MongLong0214/commitlore/issues/631) · 2026-08-13 · closed · 4 comments

### MCP capture pipeline is unreachable when the agent's session root differs from the wired repo

Found during first real use of v0.8.2, working on `MongLong0214/agent-control-plane`.

## What happened

The capture pipeline is MCP-only — `commitlore_prepare_capture`, `commitlore_verify_capture`, `commitlore_stage_capture` have no CLI equivalent (`commitlore --help` lists `parse`, `sync`, `pre-push`, `validate`, `uninstall`, `hooks`, `index`, `context`, `limits`, `ruled-out`, `warnings`).

MCP servers are loaded from the **agent session's root project**, not from the repository the agent is e

[Read the thread](https://github.com/MongLong0214/commitlore/issues/630) · 2026-08-13 · closed · 4 comments

### gemini-cli's first-run MCP probe timed out at 15s and never again — budget or first-attempt condition?

> Carried out of #716, which closed on its two named causes. This observation was not one of them and would have been lost with it.

On the Windows machine in #714, the same registration was reported dead on the first attempt and alive on the second:

fresh install gemini-cli failed "registration was written but is unhealthy: MCP initialize timed out after 15000ms" rerun gemini-cli owned healthy later e2e gemini-cli custom-preserved healthy


Nothing about the wir

[Read the thread](https://github.com/MongLong0214/commitlore/issues/729) · 2026-08-17 · closed · 3 comments

### Plugin and CLI both install a PreToolUse hook, and neither knows the other exists

**Blocker: needs a decision on which installer yields when both are present — no code change is safe until that is settled.**

Neither installer knows the other exists.

- `src/commands/init.ts` → `runAgentIntegrationStep` calls `installClaudeHook({ settingsPath })` unconditionally. It has no plugin check.
- `src/hooks/claude-settings.ts` has no awareness of `hooks/hooks.json`; nothing in `src/` reads `CLAUDE_PLUGIN_ROOT` outside `doctor`.

So a Claude Code user who follows the README (*"automat

[Read the thread](https://github.com/MongLong0214/commitlore/issues/781) · 2026-08-18 · closed · 2 comments

## Most recent

### init.test.ts fails on any machine with a stale CommitLore MCP server running

Six tests in `test/init.test.ts` fail locally and pass in CI. The difference is not the code — it is that a CI runner has no other CommitLore processes on it.

## What happens

`init`'s final step runs `doctor`, and the tests assert a clean report:

expect(text).toContain('✓ Final check') expect(exitCode).toBe(0)


On a developer machine the report comes back with exactly one warning:

! Final check — needs attention … warn live MCP runtime identity — 2 distinct live CommitLore r

Read the thread · 2026-08-18 · closed · 0 comments

install.ps1 accepts a recorded MCP command that exists but does not work

Raised from a public thread on r/ClaudeCode, where kantorcodes1 also proposed the fix evaluated below.

install.ps1 decides whether an existing commitlore MCP entry is healthy by asking whether its recorded path exists.

# install.ps1:881
if ($existingCmd -ne '' -and -not (Test-Path -LiteralPath $existingCmd)) {
    Add-Skipped $AgentName "$ConfigPath names commitlore at ""$existingCmd"", which does not exist -- left unchanged, so this host has no working server; remove that en

[Read the thread](https://github.com/MongLong0214/commitlore/issues/712) · 2026-08-16 · closed · 1 comment

### install.ps1 installs the Codex plugin and install.sh does not

Found while deleting the dead host block for #691, and it is not caused by that
deletion — the deletion revealed it.

install.ps1:1061 & $dest plugin install-codex ← reached install.sh wire_codex_plugin { … install-codex } called only from wire_codex, which nothing calls


On `main` today, `install.sh` contains the Codex plugin step and never runs it.
`install.ps1` runs it. **The two platform installers have been doing different
things**, and the shell'

[Read the thread](https://github.com/MongLong0214/commitlore/issues/697) · 2026-08-16 · closed · 2 comments

### hermes install refuses to upgrade the config it wrote, and blames the wrong key

Found installing v1.0.0 on a machine that had v0.8.2. First real-use data on the
release.

$ commitlore hermes install --config ~/.hermes/config.yaml
--command /Users/isaac/.local/bin/commitlore
--data-root ~/.local/share/commitlore --verify

could not configure: mcp_servers.commitlore already exists but does not point at this CommitLore install


`install.sh v1.0.0` exits 1 on this. Five other hosts register fine; Hermes is
the one that fails.

## The message names the wrong 

[Read the thread](https://github.com/MongLong0214/commitlore/issues/682) · 2026-08-15 · closed · 0 comments

### The MCP probe's Windows behaviour is unverified: PATHEXT resolution and child-tree cleanup

Raised from an independent audit of #636 and confirmed against the workflow: **no CI job exercises the MCP probe on Windows.**

`install-ps1` runs on `windows-latest`, but its own comment states why it stops short:

> It deliberately does not require a healthy `doctor`: on Windows the hook-runtime probe spawns `/bin/sh`, which does not exist there, and the PreToolUse entry names `commitlore` while the shim is `commitlore.cmd`.

So a green `install-ps1` says the installer works. It says nothing a

[Read the thread](https://github.com/MongLong0214/commitlore/issues/640) · 2026-08-14 · closed · 1 comment

### [R2-01] Add verified-empty assessment state and local capture fallback

<!-- COMMITLORE-SSOT key=R2-01 version=3 source=f28c22567f56562b0c140e45ba7bb67188ebb8f414eea38211701115efb3a71c -->
## Outcome
An eligible agent commit always has one terminal assessment: record-staged, verified-empty, or failed/degraded; MCP is not the sole correctness path.

## Scope
- first-class verified-empty state tied to current staged tree
- bounded local CLI fallback for MCP loss
- one retry and bounded fail-open
- privacy-safe attempt/outcome event used by #550
- reuse existing pendin

[Read the thread](https://github.com/MongLong0214/commitlore/issues/618) · 2026-08-13 · closed · 1 comment

### [R0-02] Reject malformed decoded capture drafts at the MCP boundary

<!-- COMMITLORE-SSOT key=R0-02 version=3 source=f28c22567f56562b0c140e45ba7bb67188ebb8f414eea38211701115efb3a71c -->
## Outcome
Malformed JSON record shapes are caller errors and can never look like a normal empty verification.

## Problem
The MCP outer schema validates `draft` as a string. After JSON parsing, each record is cast to `DraftRecord` without a structural boundary check. Missing `evidence`, non-array `trailers`, null records, or wrong field types can throw inside verification and be 

[Read the thread](https://github.com/MongLong0214/commitlore/issues/615) · 2026-08-13 · closed · 0 comments

### A commit with only DCO/GitHub trailers is refused as a malformed CommitLore record

## Reproduced

A repository with CommitLore installed, no CommitLore content anywhere:

    $ git commit -s -m 'feat: add a.js'
    shape failed · references not checked
    3: unknown-key Signed-off-by — got "Signed-off-by", want "a key from SPEC §3 or X-<Name>"
    commitlore: 1 violation (SPEC §6) — the message was not modified

`git commit -s` (DCO) writes exactly one trailer. So does every Dependabot commit. `validateRecord`'s `unknown-key` rule treated it as a malformed record — SPEC §2.1 

[Read the thread](https://github.com/MongLong0214/commitlore/issues/612) · 2026-08-13 · closed · 1 comment

### guard and before-change drop the signature-required policy, so a repository that demands signing is served unsigned directives

<!-- COMMITLORE-SSOT key=597 version=3 source=f28c22567f56562b0c140e45ba7bb67188ebb8f414eea38211701115efb3a71c -->
## SSOT execution contract

### Outcome
A directive is emitted only when the verified signer identity is explicitly authorized by repository policy.

### Acceptance
- valid signature by an unapproved key remains claim
- forged author header remains claim
- approved signer succeeds on commit and notes routes
- every record-serving route returns the same grade
- default author-string 

[Read the thread](https://github.com/MongLong0214/commitlore/issues/597) · 2026-08-12 · closed · 1 comment

The remaining reports are on [the project's issue tracker](https://github.com/MongLong0214/commitlore/issues).