# 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](/mcp/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](https://github.com/morluto/leantoken/issues/86) · 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](https://github.com/morluto/leantoken/issues/14) · 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](https://github.com/morluto/leantoken/issues/565) · 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:

```text
remaining_items = 0
next_cursor = None
```

even though entries between the legitimate and forged offsets were never

[Read the thread](https://github.com/morluto/leantoken/issues/535) · 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](https://github.com/morluto/leantoken/issues/196) · 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](https://github.com/morluto/leantoken/issues/163) · 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:

```json
{
  "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](https://github.com/morluto/leantoken/issues/596) · 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](https://github.com/morluto/leantoken/issues/595) · 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](https://github.com/morluto/leantoken/issues/594) · 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](https://github.com/morluto/leantoken/issues/579) · 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](https://github.com/morluto/leantoken/issues/554) · 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](https://github.com/morluto/leantoken/issues/553) · 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](https://github.com/morluto/leantoken/issues/551) · 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](https://github.com/morluto/leantoken/issues/548) · 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](https://github.com/morluto/leantoken/issues/546) · 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](https://github.com/morluto/leantoken/issues/543) · 2026-08-11 · open · 0 comments

### Regenerate or disambiguate receipt namespaces when SQLite databases are cloned

## Summary

Retrieval receipt IDs are namespace + row ID:

```text
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](https://github.com/morluto/leantoken/issues/538) · 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](https://github.com/morluto/leantoken/issues/526) · 2026-08-11 · closed · 1 comment

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