Related Pages

Related topics: Operations, Configuration, and Troubleshooting

Overview and Getting Started

ChunkHound is a code-indexing engine that turns a source tree into a searchable, embedding-backed knowledge base. It walks a project, parses each file with tree-sitter into language-aware chunks (functions, classes, blocks, literals), generates vector embeddings for those chunks, and persists everything into a local database that supports both regex and semantic-similarity queries. The system exposes its capabilities through a CLI, a programmatic Python API, and an MCP server that integrates with editors such as Claude Code. Source: README.md:1-40 Source: pyproject.toml:1-60

The project targets two main use cases: (1) letting LLM agents query a large codebase through the MCP search tool instead of stuffing raw files into a context window, and (2) letting humans run fast regex and semantic searches across millions of lines without spinning up a remote service. Source: CHANGELOG.md:1-30

Architecture and Data Flow

At runtime, ChunkHound follows a four-stage pipeline. The file walker discovers supported files based on language registrations, the parser converts each file into a list of chunk records via a tree-sitter grammar, the embedder batches chunk text through a pluggable embedding provider, and the storage layer writes chunks plus vectors into a local DuckDB/LanceDB instance. Queries (CLI or MCP) read from the same store and can return either raw matches or ranked semantic hits. Source: chunkhound/api.py:1-80 Source: chunkhound/cli.py:1-120

flowchart LR
    A[File Walker] --> B[Tree-sitter Parser]
    B --> C[Chunk Records]
    C --> D[Embedding Provider]
    D --> E[(Local DB)]
    E --> F[Search / MCP]
    F --> G[LLM Agent]

The parser layer is modular: each supported language ships its own tree-sitter grammar binding and a chunker that maps AST nodes to ChunkHound's internal Chunk schema (file, start line, end line, kind, symbol, code, language). Source: chunkhound/api.py:80-160

Installation and First Run

ChunkHound is distributed as a Python package and is typically installed with uv or pip. The package metadata declares the supported Python versions, the optional provider extras (OpenAI, Voyage, Ollama, etc.), and the entry points that wire the chunkhound console script to the CLI module. Source: pyproject.toml:60-140

A typical first session looks like:

1. uv tool install chunkhound (or pip install chunkhound) Source: pyproject.toml:140-200
2. cd /path/to/your/repo
3. chunkhound init — creates .chunkhound.json via the setup wizard when none is present Source: chunkhound/cli.py:120-200
4. chunkhound index — walks the repo, parses files, and writes chunks + embeddings to the configured database Source: chunkhound/cli.py:200-280
5. chunkhound search "authentication middleware" — runs a hybrid semantic + regex query and prints ranked results Source: chunkhound/cli.py:280-360

Configuration lives in .chunkhound.json and is loaded by the config module, which merges CLI flags, environment variables, and file values. Key knobs include the embedding provider and model, the database path, include/exclude globs, and chunk-size limits. Source: chunkhound/config.py:1-120

MCP Integration and Known Limitations

For LLM workflows, ChunkHound runs as a stdio MCP server: agents launch chunkhound mcp as a subprocess and call the search, code_research, autodoc, and codemap tools over the Model Context Protocol. The HTTP MCP transport was removed in v5.0.0, so users on the latest releases must use stdio. Source: CHANGELOG.md:30-90 Source: chunkhound/version.py:1-20

A few community-reported limitations are worth knowing up front. Embedding generation can fail when scanned files contain certain non-text characters (#315), the Makefile cAST chunker can produce chunks that exceed max_chunk_size (#352), and ruff check currently surfaces around 820 pre-existing style violations in the repo (#349). Multiple concurrent MCP instances pointing at the same directory are not officially supported and can cause stdio crashes (#53). Source: CHANGELOG.md:90-180

Where to Go Next

After the first successful index, the recommended next steps are: tune .chunkhound.json (embedding model, exclude patterns, chunk-size cap) for the target repo; wire ChunkHound into Claude Code or another MCP-aware client via stdio; and explore the higher-level tools such as codemap for repository-wide structure summaries and autodoc for generated documentation. Contributors should read CONTRIBUTING.md before opening a PR. Source: CONTRIBUTING.md:1-60

Related Pages

Related topics: Providers, MCP Server, and Extensibility, Operations, Configuration, and Troubleshooting

System Architecture

ChunkHound is a code-indexing and semantic-search engine designed to turn a source tree into queryable chunks that can be served to LLM clients (e.g. Claude Code) over the Model Context Protocol (MCP). The system is split into a *parsing pipeline*, a *storage layer*, an *embedding/LLM provider layer*, and an *interface layer* (CLI + MCP server). All long-running work is coordinated by a single service that owns file discovery, deduplication, batching, and persistence.

1. High-Level Pipeline

At runtime ChunkHound executes a four-stage pipeline: Discover → Parse → Embed → Query. Discovery walks the filesystem, hashing files for incremental indexing; parsing converts raw text into language-aware chunks via tree-sitter; embedding batches chunks through a pluggable provider; queries combine regex and vector similarity to return ranked results. The CLI and MCP server share the same coordinator, so both surfaces operate on the same on-disk index.

flowchart LR
    A[Filesystem] --> B[IndexingCoordinator]
    B --> C[ParserFactory → UniversalParser]
    C --> D[DuckDBProvider]
    D --> E[EmbeddingProvider]
    E --> D
    F[CLI / MCP Server] --> G[Search Service]
    G --> D
    G --> E

The coordinator is the only component allowed to write to the database; read paths (CLI search, MCP search, code_research, autodoc, codemap) go through dedicated query services that share the same DuckDB connection. Source: chunkhound/services/indexing_coordinator.py:1-120.

2. Parsing Subsystem

Parsing is built around a *universal* tree-sitter engine rather than per-language parsers. The ParserFactory resolves a language from a file extension and returns a configured UniversalParser; the engine then walks the syntax tree and emits chunks keyed off a per-language mapping (functions, classes, methods, imports, config literals, embedded SQL, etc.).

• ParserFactory selects a parser by extension and language metadata. Source: chunkhound/parsers/parser_factory.py:1-90.
• UniversalParser orchestrates tree-sitter parsing, chunk size enforcement, and fallback heuristics for plain-text/PDF files. Source: chunkhound/parsers/universal_parser.py:1-200.
• UniversalEngine is the tree-sitter abstraction that the parser and per-language mappings share. Source: chunkhound/parsers/universal_engine.py:1-180.
• Language mappings (e.g. Python) define which AST node types become which chunk kinds. Source: chunkhound/parsers/mappings/python.py:1-160.

Chunk-size enforcement is a recurring source of bugs in this layer — for example, Makefile cAST chunks have been observed to exceed the configured max_chunk_size (1350), which fails the parser-level invariant test test_all_parsers_respect_chunk_size_constraints. This is tracked as a pre-existing main-branch issue (see #352) and motivates tighter per-language size policies in the engine.

3. Storage and Provider Layer

The default backend is DuckDB, exposed through a DatabaseProvider interface that hides SQL behind typed methods (insert_files, insert_chunks, search_regex, search_vector, search_hybrid). Schema migrations and embedding tables live alongside the provider so a single file change can re-index incrementally. Source: chunkhound/providers/database/duckdb_provider.py:1-260.

Embeddings are abstracted behind an EmbeddingProvider protocol. v5.0.0 added six new providers (e.g. OpenAI-compatible, Voyage, Cohere, Gemini, local transformers), all implementing the same embed(chunks) → vectors contract. v5.1.0 tightened the embedding pipeline to recover gracefully from files containing null/replacement characters, which previously surfaced as [EmbSvc-L101] Failed to generate embeddings (see #315) when scanning repositories with corrupted or non-UTF-8 content. Source: chunkhound/providers/embeddings/openai_provider.py:1-140.

A separate set of LLMProvider implementations backs synthesis features (autodoc, code_research). These providers are stateless wrappers around model APIs and are intentionally decoupled from embedding providers so the two can evolve independently.

4. Interface Layer

Two surfaces consume the same coordinator and database:

• CLI — exposed via chunkhound (Typer-based). Commands include index, search, autodoc, codemap, and the setup wizard that runs when .chunkhound.json is absent. The CLI bootstraps config, builds the coordinator, and dispatches. Source: chunkhound/api/cli.py:1-220.
• MCP server — stdio-only since v5.0.0 (HTTP transport was removed as a breaking change). The server registers tools such as search, code_research, and autodoc, each implemented as a thin adapter over the search service. v5.1.0 switched MCP responses to a *lean markdown* format (syntax-highlighted code fences with similarity scores) to reduce token overhead. Source: chunkhound/mcp/server.py:1-260.

Concurrency is a known friction point: running multiple stdio MCP clients against the same project directory can crash the daemon because DuckDB writes are not multi-writer safe (see #53). The recommended workaround is one long-running MCP server per project, or using worktree-aware configurations (see #83).

5. Configuration and Extension Points

Configuration is loaded once at startup from .chunkhound.json and environment variables, producing a Config object that is passed explicitly to services rather than read globally. This makes the coordinator trivially testable and lets embed/embedding providers be swapped without code changes. Source: chunkhound/core/config.py:1-180.

Extension is deliberately narrow:

This separation is what allows ChunkHound to keep adding breadth (4 languages and 6 providers in v5.0.0, PDF parsing in v3.1.0, embedded SQL detection in v5.0.0) without entangling parsing, storage, and serving layers.

Related Pages

Related topics: System Architecture, Operations, Configuration, and Troubleshooting

Providers, MCP Server, and Extensibility

ChunkHound's flexibility for code indexing and AI-assisted search comes from a clean provider abstraction that separates embedding generation, LLM-driven synthesis, and the Model Context Protocol (MCP) transport. This page describes how providers are organized, how new ones are added, and how the MCP server ties them to client applications such as Claude Code or other MCP-aware editors.

Provider Abstraction Overview

The codebase separates external services into two parallel trees under chunkhound/providers/:

• Embeddings — used during indexing to vectorize code chunks for semantic search.
• LLM — used at query time for synthesis, expansion, and agentic code research.

Each concrete provider implements a small interface (typically name, dimensions, batched embed/generate, health checks, and provider-specific options), allowing the registry to pick a provider purely from configuration. New services can be slotted in by subclassing without touching the rest of the pipeline. Source: chunkhound/providers/embeddings/openai_provider.py:1-1 and Source: chunkhound/providers/llm/anthropic_llm_provider.py:1-1.

Embedding Providers

The embedding tree hosts remote API providers behind a common shape so the indexing pipeline can iterate them uniformly.

• OpenAI embeddings implement the OpenAI /v1/embeddings endpoint contract, accepting model name, batch size, and optional API key/base URL overrides. Source: chunkhound/providers/embeddings/openai_provider.py:1-1.
• VoyageAI embeddings wrap Voyage's /v1/embeddings API, useful for code-tuned embedding models and commonly paired with Voyage rerankers for higher-quality retrieval. Source: chunkhound/providers/embeddings/voyageai_provider.py:1-1.

Both providers expose the dimensionality the vector database needs to size its columns, and they are resilient to network errors by batching and retrying per chunk group. Community reports such as issue #315 (NUL bytes causing embedding failures) trace back to the embedding service's input sanitization rather than the provider protocol itself.

LLM Providers

LLM providers fall into two families: HTTP API providers that call hosted models directly, and CLI providers that delegate to a local agentic CLI (Claude Code, OpenCode).

• Anthropic LLM provider targets Anthropic's Messages API and is the default for Claude-family models used in synthesis and code research. Source: chunkhound/providers/llm/anthropic_llm_provider.py:1-1.
• OpenAI LLM provider targets OpenAI's chat completions API and accepts any OpenAI-compatible endpoint (custom base_url, optional API key for local servers, per v3.0.1). Source: chunkhound/providers/llm/openai_llm_provider.py:1-1.
• Claude Code CLI provider shells out to the locally installed claude CLI in non-interactive mode, reusing the user's authentication and tool sandbox rather than maintaining a separate API key. Source: chunkhound/providers/llm/claude_code_cli_provider.py:1-1.
• OpenCode CLI provider mirrors the Claude Code CLI pattern but invokes the OpenCode CLI (see community request #113). Source: chunkhound/providers/llm/opencode_cli_provider.py:1-1.

The CLI pair is a deliberate extensibility point: any agentic CLI that supports a non-interactive "answer this prompt" mode can be wrapped in the same interface, giving ChunkHound free support for new agent runtimes.

MCP Server and Extensibility

ChunkHound exposes its tools over the Model Context Protocol. Starting with v5.0.0, the HTTP MCP transport was removed in favor of stdio, and a multi-client daemon was introduced so multiple Claude Code sessions can safely share one database. The MCP server is the integration surface where providers, the database layer, and search/expansion logic meet an LLM client.

flowchart LR
    Client["MCP Client (Claude Code, etc.)"] -- stdio --> Server["ChunkHound MCP Server"]
    Server --> Emb["Embedding Providers<br/>(OpenAI, VoyageAI)"]
    Server --> LLM["LLM Providers<br/>(Anthropic, OpenAI,<br/>Claude Code CLI, OpenCode CLI)"]
    Emb --> DB["Vector + Relational DB"]
    LLM --> Server
    Server --> Client

Adding a new capability typically follows one of three patterns:

1. New embedding or LLM provider — add a file under chunkhound/providers/embeddings/ or chunkhound/providers/llm/, register it in the provider factory, and surface its options in config validation.
2. New CLI-backed agent — copy the claude_code_cli_provider.py shape, swap the executable and prompt flags, and reuse the existing process and timeout handling.
3. New MCP tool — extend the server module to expose the tool, keep responses in the lean markdown format introduced in v5.1.0, and rely on the provider abstraction for any model calls.

The combination of a strict provider interface, a stdio MCP transport, and a registry-driven CLI bridge keeps the system open: contributors can add languages, embedding models, or agentic CLIs without re-architecting the indexing or query layers. Source: chunkhound/providers/llm/claude_code_cli_provider.py:1-1 and Source: chunkhound/providers/llm/opencode_cli_provider.py:1-1.

Operational Notes from the Community

A few recurring operational points inform how providers should be configured:

• Multiple concurrent MCP instances against the same database are supported through the multi-client daemon introduced in v5.0.0; the legacy stdio crash mode and the removed HTTP server are no longer relevant. (Issue #53.)
• OpenAI-compatible providers accept optional API keys, which is required for connecting to local servers (e.g., Ollama) without secrets. (v3.0.1 release notes.)
• Embedding provider robustness against malformed input (e.g., NUL bytes in source files, issue #315) is a shared responsibility between file scanners and the embedding service's input handling, not the provider protocol itself.

Together these layers form ChunkHound's extension model: providers handle model I/O, the MCP server handles transport and orchestration, and contributors add new entries at either layer without disturbing the other.

Related Pages

Related topics: Overview and Getting Started, Providers, MCP Server, and Extensibility

The following source files were used to generate this page:

• chunkhound/api/cli/main.py
• chunkhound/api/cli/commands/run.py
• chunkhound/api/cli/commands/search.py
• chunkhound/api/cli/commands/research.py
• chunkhound/api/cli/commands/daemon.py
• chunkhound/api/cli/commands/mcp.py
• chunkhound/core/config.py
• chunkhound/services/embedding_service.py
• chunkhound/api/cli/commands/setup_wizard.py
• chunkhound/database.py

Operations, Configuration, and Troubleshooting

Overview

ChunkHound is operated through a Click-based command-line interface rooted in chunkhound/api/cli/main.py, which dispatches to a set of subcommands covering indexing, searching, research, daemonisation, and Model Context Protocol (MCP) integration. The CLI also bootstraps a configuration wizard when no .chunkhound.json is found in the working directory, lowering the barrier to first-time use. Source: chunkhound/api/cli/main.py:1-80.

The CLI surface is intentionally narrow: chunkhound run (the historical entry point, now an alias that delegates to the indexer), chunkhound search, chunkhound code-research, chunkhound mcp, chunkhound daemon, and chunkhound init (the setup wizard). Each subcommand lives in its own module under chunkhound/api/cli/commands/, which keeps lifecycle handling for long-running services (embeddings, MCP servers) isolated from one-shot commands. Source: chunkhound/api/cli/commands/run.py:1-60, chunkhound/api/cli/commands/search.py:1-40, chunkhound/api/cli/commands/mcp.py:1-50.

Configuration

The single source of truth for runtime configuration is the .chunkhound.json file in the project root. Schema resolution, defaults, and environment overrides are handled by chunkhound/core/config.py, which produces a typed Config object consumed by every command. The setup wizard writes this file interactively, prompting for provider, model, and database choices, and is invoked automatically when the file is missing. Source: chunkhound/api/cli/commands/setup_wizard.py:1-120, chunkhound/core/config.py:1-100.

Key configuration areas include:

• Embedding provider: provider (e.g. openai, ollama, voyage, tei) and model identifiers. The list of supported providers has expanded across releases — v5.0.0 added six new embedding/LLM providers and the latest Claude and OpenAI models. Source: chunkhound/core/config.py:120-220.
• Database: DuckDB is the default backend; the path is resolved relative to the project root. v5.1.0 introduced fixes that prevent crashes on startup if the database file is in an inconsistent state. Source: chunkhound/database.py:1-80.
• Indexing scope: include/exclude glob patterns, file-size limits, and the max_chunk_size ceiling enforced by parsers. Source: chunkhound/core/config.py:200-320.
• MCP server: transport (stdio is the only supported transport after v5.0.0 removed HTTP MCP), and the working directory served by the daemon. Source: chunkhound/api/cli/commands/mcp.py:40-120.

Environment variables prefixed CHUNKHOUND_ override file values, which is the recommended path for CI pipelines and container deployments.

Operations: Indexing, Search, and Serving

The run command (and its modern equivalents) drives the indexer pipeline: file discovery, parsing via tree-sitter, chunk emission, and asynchronous embedding generation. The embedding subsystem in chunkhound/services/embedding_service.py batches calls and logs per-batch failures with chunk IDs and character counts so operators can correlate lost data with log lines. Source: chunkhound/api/cli/commands/run.py:60-180, chunkhound/services/embedding_service.py:1-160.

chunkhound search exposes the same backends used by MCP tools without requiring an MCP client: it accepts both regex patterns and natural-language queries, persisting results to stdout. Source: chunkhound/api/cli/commands/search.py:40-140.

The mcp command launches a long-lived stdio server that serves code_research, search, and related tools to MCP clients such as Claude Code. From v5.0.0 onward, the HTTP transport has been removed; all integrations must be configured with command/args/env (stdio) JSON in the client. Source: chunkhound/api/cli/commands/mcp.py:80-200.

Troubleshooting

The following symptoms are recurring in the issue tracker and have known remediations.

• Embeddings fail with Failed to generate embeddings (chunks: N, total_chars: M): usually a special token (<|endoftext|>, <|endofbeginoftext|>, etc.) reaches the tokenizer and causes a 400/422 error on the provider side. Issue #315 documents this; the practical workaround is to add the offending paths to .chunkhound.json exclude patterns or pre-process the files. Source: chunkhound/services/embedding_service.py:180-260, issue #315.
• Parser chunk-size violations: test_all_parsers_respect_chunk_size_constraints reports Makefile cAST chunks larger than the 1350-character ceiling. This is a known regression on the Makefile parser and needs a parser-level fix rather than a configuration change. Source: issue #352, chunkhound/core/config.py:240-320.
• Multiple concurrent MCP instances: Running two chunkhound mcp processes against the same project causes stdio crashes or empty semantic-search results because the embedded DuckDB lock is shared. v5.0.0's multi-client daemon was the intended remedy; for older versions, serialise clients or use the HTTP daemon, issue #53.
• Database startup crashes: caused by stale .chunkhound.db files left by interrupted runs. Re-running with the --reinit flag (or removing the file) clears the lock and migrates schema. Source: chunkhound/database.py:60-160, v5.1.0 release notes.
• Ollama/Qwen3 embedding models returning empty vectors: some quantised models (e.g. dengcao/Qwen3-Embedding-8B:Q5_K_M) do not implement the OpenAI-compatible /v1/embeddings endpoint that TEI-style adapters expect. Switch to a non-quantised build or use the native TEI provider. Source: issue #41, chunkhound/core/config.py:160-220.
• Lint failures before PR: developers are directed by CONTRIBUTING.md to run uv run ruff check chunkhound. Issue #349 records ~820 pre-existing violations, so configuration should pin to per-file ignores until the codebase is cleaned up. Source: issue #349.

For deeper diagnostics, enable verbose logging via CHUNKHOUND_LOG_LEVEL=DEBUG. The CLI emits structured JSON on stderr when CHUNKHOUND_LOG_FORMAT=json, which simplifies log shipping from containerised deployments. Source: chunkhound/api/cli/main.py:60-200.

Doramagic Pitfall Log

Found 37 structured pitfall item(s), including 8 high/blocking item(s). Top priority: Installation risk - Installation risk requires verification.

1. Installation risk: Installation risk requires verification

• Severity: high
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/chunkhound/chunkhound/issues/168

2. Configuration risk: Configuration risk requires verification

• Severity: high
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/chunkhound/chunkhound/issues/41

3. Maintenance risk: Maintenance risk requires verification

• Severity: high
• Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/chunkhound/chunkhound/issues/133

4. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/chunkhound/chunkhound/issues/232

5. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/chunkhound/chunkhound/issues/145

6. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/chunkhound/chunkhound/issues/210

7. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/chunkhound/chunkhound/issues/154

8. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/chunkhound/chunkhound/issues/363

9. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: ChunkHound v3.3.1
• User impact: Upgrade or migration may change expected behavior: ChunkHound v3.3.1
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: ChunkHound v3.3.1. Context: Source discussion did not expose a precise runtime context.
• Evidence: failure_mode_cluster:github_release | https://github.com/chunkhound/chunkhound/releases/tag/v3.3.1

10. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: ChunkHound v4.0.0
• User impact: Upgrade or migration may change expected behavior: ChunkHound v4.0.0
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: ChunkHound v4.0.0. Context: Observed when using python
• Evidence: failure_mode_cluster:github_release | https://github.com/chunkhound/chunkhound/releases/tag/v4.0.0

11. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: ChunkHound v5.0.0
• User impact: Upgrade or migration may change expected behavior: ChunkHound v5.0.0
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: ChunkHound v5.0.0. Context: Observed when using python
• Evidence: failure_mode_cluster:github_release | https://github.com/chunkhound/chunkhound/releases/tag/v5.0.0

12. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: ChunkHound v5.1.0
• User impact: Upgrade or migration may change expected behavior: ChunkHound v5.1.0
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: ChunkHound v5.1.0. Context: Observed when using docker
• Evidence: failure_mode_cluster:github_release | https://github.com/chunkhound/chunkhound/releases/tag/v5.1.0

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using chunkhound with real data or production workflows.

• VoyageAI-compatible endpoints with a native /rerank (top_k / data) can't - github / github_issue
• feat: MCP HTTP server transport (Streamable HTTP / SSE) - github / github_issue
• MCP Disconnects - github / github_issue
• Embedding batches fail in non-TTY mode: '_Task' object has no attribute - github / github_issue
• Disk space usage of chunkhound - github / github_issue
• ruff check (per CONTRIBUTING) surfaces ~820 pre-existing violations, i - github / github_issue
• Embedding fails with Ollama: '_Task' object has no attribute 'elapsed' + - github / github_issue
• dengcao/Qwen3-Embedding-8B:Q5_K_M model doesn't support embedding - github / github_issue
• VoyageAI reranking failed with non-retryable error - github / github_issue
• OpenAI provider fails to handle 'input length exceeds the context length - github / github_issue
• max_disk_usage_mb not enforced during CLI bulk indexing — DB grew to 202 - github / github_issue
• Ollama reranking does not work - github / github_issue