# Reported issues for ivygrep

Pod holds 8 of 8 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 [ivygrep](/mcp/ivygrep).

## Most discussed

### [Bug]: regex search ignores type and context options

## What happened?

CLI, MCP, and Web accept type/context options for regex search, but `DaemonRequest::RegexSearch` and local regex implementation carry neither field.

## Minimal reproduction

```shell
ig --regex --type markdown --context 10 --json --limit 1 \
  'pub fn regex_search' .
```

Observed Rust file `src/regex_search.rs` with `start_line == end_line`. Both Markdown filter and context 10 were ignored.

## Expected behavior

Regex mode honors same documented type filter and context cont

[Read the thread](https://github.com/bvolpato/ivygrep/issues/214) · 2026-08-04 · closed · 0 comments

### MCP: keep coding-agent indexes fresh and simplify setup

## Problem

An MCP-only coding-agent session can auto-index a workspace but does not keep a watcher alive. Edits made after the first query can therefore remain absent until another CLI operation reconciles the index. On Windows, daemon auto-spawn also rejects the packaged `ig.exe` filename.

The agent setup documentation has drifted across clients, and release installation requires too many manual steps.

## Reproduction

1. Start `ig --mcp` with an isolated `IVYGREP_HOME`.
2. Call `ig_search` 

[Read the thread](https://github.com/bvolpato/ivygrep/issues/135) · 2026-06-17 · closed · 0 comments

### P1: MCP server reloads the neural embedding model on every request

## Performance (P1)

`src/mcp.rs::execute_ivygrep_search` calls `create_model(false)` on **every** `ig_search` request. `serve_stdio` is a long-lived process, so this reconstructs the Candle/ONNX model (load tokenizer + weights) per call — hundreds of ms of avoidable latency on every search, plus memory churn.

The daemon already loads the model once into an `Arc<OnceLock<..>>` (`DaemonState.lazy_model`) and `cached_hash_model()` uses the same pattern. The MCP server should cache its query model

[Read the thread](https://github.com/bvolpato/ivygrep/issues/57) · 2026-05-25 · closed · 0 comments

### P0: MCP auto-index embeds inline with the neural model → first query hangs on large repos; parallel MCP melts the host

## Stability / Performance (P0)

The MCP auto-index path embeds **every chunk with the neural ONNX model inline**, on the first query. `src/mcp.rs::execute_ivygrep_search` does:

```rust
let model = create_model(false);            // neural (384-dim), loaded per request
...
if !workspace_is_indexed(&current_workspace) {
    let _summary = index_workspace(&current_workspace, model.as_ref())?;   // <-- neural model passed to the indexer
}
```

`index_workspace` then calls `embedding_model.embed_ba

[Read the thread](https://github.com/bvolpato/ivygrep/issues/56) · 2026-05-25 · closed · 0 comments

### A search panic crashes the entire MCP server (no panic isolation)

## Robustness (P1)
The MCP server runs single-threaded with no panic isolation (`src/mcp.rs`): a panic anywhere in `dispatch`→`execute_ivygrep_search`→search unwinds through `serve_stdio` and **crashes the whole MCP session**. (The daemon isolates each connection in a tokio task; MCP does not.) Wrap tool-call handling in `catch_unwind` and return a JSON-RPC error.

[Read the thread](https://github.com/bvolpato/ivygrep/issues/53) · 2026-05-23 · closed · 0 comments

### Unbounded request/Content-Length sizes on MCP and daemon transports (OOM DoS)

## Robustness / DoS (P1)
- MCP `Content-Length` framing allocates `vec![0u8; len]` with `len` straight from the client header and **no upper bound** (`src/mcp.rs`) → trivial OOM.
- Both the daemon (`src/daemon.rs`) and MCP use unbounded `read_line`, so a client streaming a huge line without a newline grows memory without bound.

Cap request/frame size and reject oversized input with an error instead of allocating.

[Read the thread](https://github.com/bvolpato/ivygrep/issues/51) · 2026-05-23 · closed · 0 comments

### MCP --all search returns no results for indexed workspaces (CLI --all works)

## Finding (unfixed — needs investigation)
The MCP server's `--all` (all-indices) search returns **zero results** even when the target workspaces are indexed and registered (verified: `ig --status` lists them with `last_indexed_at_unix` set), whereas the **CLI** `ig --all` finds the same content correctly with absolute paths.

Reproduction:
1. `ig --add repoA --hash --no-watch`; `ig --add repoB --hash --no-watch` (same `IVYGREP_HOME`).
2. CLI: from repoA, `ig --all --literal "<content only in re

[Read the thread](https://github.com/bvolpato/ivygrep/issues/43) · 2026-05-23 · closed · 0 comments

### MCP --all returns workspace-relative paths under a single workspace_root

## Bug
The MCP server runs `--all` (all-indices) search in-process, merging hits from multiple workspaces but reporting a single `workspace_root` while leaving each `hit.file_path` workspace-relative (`src/mcp.rs`). A consumer joining `workspace_root + file_path` resolves hits from other workspaces against the wrong root. The daemon path already rewrites these to absolute.

## Fix
Rewrite each hit to an absolute path per source workspace in the MCP all-indices branch, mirroring the daemon.

[Read the thread](https://github.com/bvolpato/ivygrep/issues/41) · 2026-05-23 · closed · 0 comments

## Most recent

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