pod
Other formats agents might prefer:
markdownjsonllms.txt

Agent? You probably want markdown or json, or Pod over MCP.

Reported issues for LeanToken

Pod holds 20 of 102 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 LeanToken.

Most discussed

MCP server defaults to indexing $HOME and exhausts memory

Summary

leantoken mcp was launched from ~ and immediately consumed 10.3 GB of physical memory while trying to index $HOME.

Observed behavior

  • Process: leantoken mcp (PID 77771)
  • Parent: npm exec leantoken mcp running in $HOME
  • Memory: 8.6 GB MALLOC_SMALL + 7.1 GB compressed/swapped
  • SQLite index remained basically empty (4 KB index.sqlite, 137 KB WAL)
  • Several tokio worker threads pinned at ~85 % CPU
  • The walker was descending into `~/.cache/uv/.../pandas/tests

Read the thread · 2026-07-20 · closed · 3 comments

mcp: evaluate progressive retrieval and evidence handoffs in agent traces

Motivation

LeanToken recommends files → outline/search → exact read → context when uncertain, and returns hashes and compact receipts for handoffs. The protocol supports that workflow, but there is not yet real-model evidence that the descriptions and receipts reduce broad reads, repeated reads, or handoff reconstruction.

Adding more guidance or a runtime “next action” field without traces could increase schema cost without changing agent behavior.

Proposed solution

Use the model-in-

Read the thread · 2026-07-16 · closed · 3 comments

Make approved repository contexts lazy and enforce process-wide indexing/retrieval budgets

Summary

MCP startup eagerly opens and starts an automatic indexing loop for every approved repository context, even when the client never selects that context.

Each context owns independent indexing workers, a blocking retrieval executor, a SQLite reader pool, watcher/coordination state, and per-repository discovery limits. The primary repository owns another complete copy.

With the configured maximum of eight contexts, all nominally bounded capacities are multiplied by nine at the process

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

Authenticate JSON key cursor offsets so pages cannot skip pointers

Summary

JSON key cursors bind the source-content fingerprint and normalized query identity, but they do not bind or authenticate the cursor offset. A caller—or accidental cursor corruption—can change only the plaintext offset to any in-range value and LeanToken will accept it.

The forged offset can skip arbitrary JSON-pointer entries and produce a terminal page with:

remaining_items = 0
next_cursor = None

even though entries between the legitimate and forged offsets were never

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

Expose source provenance and runtime-evidence boundaries in MCP responses

Motivation

LeanToken is a read-only source discovery and bounded retrieval layer for coding agents. During a cross-platform CI investigation, source retrieval was useful for locating the ownership, launcher, package-verifier, and test code, but it could not establish facts about generated dist output, macOS process-table state, subprocess timing, or remote CI results.

The current retrieval contract can therefore give an agent relevant source without making the remaining proof boundary suf

Read the thread · 2026-07-24 · closed · 2 comments

Cold MCP indexing monopolizes CPU and makes tools unavailable

Description

A cold leantoken mcp start on a valid repository root can spend minutes building generation 1, consume roughly one CPU core, and make other LeanToken processes fail on SQLite contention. The MCP process answers the protocol handshake first, but Codex can still mark LeanToken's tools unavailable while the cold build is running.

This is separate from the broad-root/OOM incident in #157 and the unbounded reconcile report in #148: the root here was /root/preference, not $HOME,

Read the thread · 2026-07-22 · closed · 2 comments

Align leantoken.read range target documentation with the accepted target schema

Description

The leantoken.read target contract is not discoverable from the published tool description: the description says the reader accepts a range target, but the server rejects the corresponding kind: "range" variant during argument deserialization.

Steps to reproduce

  1. Call leantoken.read with a line-range target:
{
  "path": "src/jacobian/domains/polynomial/jacobian_syzygy.py",
  "target": {
    "kind": "range",
    "start_line": 318,
    "end_line": 409
  },
  "

[Read the thread](https://github.com/morluto/leantoken/issues/585) · 2026-08-16 · closed · 1 comment

### Disable repository-configured external diff helpers when collecting Git hunk evidence

## Summary

LeanToken disables `core.fsmonitor` for its `git diff` subprocesses, but the hunk-producing path still allows Git's configured external diff machinery.

A repository-local `diff.external` command is therefore executed when LeanToken collects diff hunks for context/workflow evidence. The helper runs with the LeanToken process user's host authority and environment. It can also replace the expected unified diff with arbitrary or empty output, so the resulting hunk evidence may be silent

[Read the thread](https://github.com/morluto/leantoken/issues/561) · 2026-08-11 · closed · 1 comment

## Most recent

### Make approved repository contexts discoverable to MCP callers

## Motivation

LeanToken supports up to eight named, approved alternate repository contexts, but an MCP-only caller cannot discover which names are available.

Every retrieval tool accepts an optional `repository_context` string. Calling one with an unknown name returns:

```json
{
  "category": "invalid_input",
  "field": "repository_context",
  "message": "invalid repository_context: must name an approved repository context",
  "status": "error"
}

The connected MCP catalog has no context-

Read the thread · 2026-08-25 · open · 0 comments

Search MCP schema collapses the tagged operation to unknown

Description

The connected LeanToken MCP catalog exposes search.operation as unknown, even though the server source defines SearchMcpOperation as a closed tagged enum with six variants and a substantial shared option contract.

Other tagged LeanToken operations such as files, history, and json remain structurally typed in the same client. Search callers therefore lose field discovery and validation before invocation and must reconstruct the request from prose or runtime errors.

A

Read the thread · 2026-08-25 · open · 0 comments

Exhaustive search work-limit errors provide no usable recovery path

Description

An exhaustive search request can stop at the candidate-work bound without returning occurrences, a cursor, or a replayable recovery action. The error recommends increasing max_tokens, but retrying at the protocol maximum reproduces the same failure at a proportionally larger candidate-byte limit.

This leaves callers unable to recover the omitted search population without manually redesigning the query.

Steps to reproduce

Run this MCP search against the SymPy repository:

Read the thread · 2026-08-25 · open · 0 comments

Structured-only MCP results can disappear in host adapters

Description

LeanToken's default MCP result mode is structured, which returns a populated structuredContent field and an empty content array. A current Codex MCP host path preserved the tool call but did not materialize structuredContent for the model, so successful retrievals appeared empty.

doctor still reports ready because it verifies the MCP response's structuredContent; it cannot attest what an intermediate host adapter forwards to the model.

Steps to reproduce

  1. Star

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

Do not advance a caller-known receipt before its response is delivered

Summary

LeanToken appends newly selected evidence to an existing retrieval receipt inside the service call, before the MCP transport writes the response to stdout.

If response delivery fails—a broken pipe, client disconnect, cancelled response, host termination, or write/flush error—the caller still knows the original receipt ID, but that receipt has already advanced. Retrying the same retrieval with the same ID suppresses exact/overlapping evidence that the caller never received.

This vio

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

Reject duplicate JSONC configuration keys before editing shadowed entries

Summary

LeanToken’s JSONC setup editor accepts duplicate object property names and edits only the first matching property. The same jsonc-parser semantic conversion—and ordinary JSON object semantics used by common clients—keeps the last duplicate value.

A client configuration can therefore contain two mcpServers properties or two leantoken properties. Setup updates/removes the first occurrence, reports success, and verifies the edited text, while the effective last occurrence

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

Bound JMESPath evaluation before materializing amplified selector results

Summary

LeanToken applies max_items and max_tokens only after a JMESPath expression has been evaluated and converted into an owned serde_json::Value.

JMESPath multiselect lists can evaluate the same large input value many times. The Rust JMESPath engine can represent those repeated values internally with reference-counted nodes, but LeanToken immediately serializes the complete result into a new owned JSON value. A selector under the current 4 KiB expression limit can therefore ex

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

Use per-artifact runtime leases instead of treating only the pruning executable as active

Summary

runtime list and runtime prune claim to identify and protect active private runtimes, but the implementation marks a runtime active only when its executable path equals the executable of the current list/prune process.

It does not detect another running LeanToken/MCP process using a different private-runtime artifact. Once that artifact is no longer referenced by a currently readable client configuration, prune can classify it as inactive and remove it while the process is s

Read the thread · 2026-08-11 · open · 0 comments

Pass validated repository filenames to Git as literal pathspecs

Summary

LeanToken validates user/discovered paths as repository-relative filesystem paths, then passes several of those exact filenames to Git commands as ordinary pathspec arguments.

Git does not interpret every pathspec argument literally. Valid Unix filenames beginning with pathspec magic such as :(literal) or :(exclude) are interpreted as selectors. This can make immutable blob reads report a real file as missing, make scoped diff evidence inspect a different file, make an explicitl

Read the thread · 2026-08-11 · closed · 1 comment

Make staged relational publication cancellable before the commit boundary

Summary

LeanToken’s reconciliation APIs accept cooperative cancellation and check it throughout discovery, hashing, parsing, staging, FTS rebuild boundaries, and immediately before commit/checkpoint. However, the normalized stage is copied into the production database inside BEGIN IMMEDIATE without any cancellation input or check.

Once FinalizedReconciliation::apply begins, cancellation cannot be observed until every staged removal, file, chunk, symbol, reference, import, and import can

Read the thread · 2026-08-11 · open · 0 comments

Regenerate or disambiguate receipt namespaces when SQLite databases are cloned

Summary

Retrieval receipt IDs are namespace + row ID:

r{32-hex database namespace}{16-hex row id}

The namespace is generated once and stored inside SQLite. Copying or restoring the database copies that namespace, SQLite sequence, and existing rows. Two database clones can then diverge while issuing identical public receipt IDs for different evidence.

This becomes directly observable in one MCP server because approved contexts may use the same canonical repository root as the p

Read the thread · 2026-08-11 · closed · 1 comment

Bound every process-test command by time and captured output

Summary

LeanToken's real-process tests isolate environment and use process groups for the long-lived MCP fixture, but most one-shot CLI/doctor/runtime commands still call .output() with no command-level deadline or output bound. The MCP fixture also feeds stdout through an unbounded channel and captures stderr with read_to_end into an unbounded Vec.

A hung command therefore consumes the entire nextest per-test timeout, and a runaway output regression can consume arbitrary memory befor

Read the thread · 2026-08-11 · closed · 1 comment

The remaining reports are on the project's issue tracker.