# Reported issues for sverklo

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

## Most discussed

### sverklo init --global: one-time setup with memory import, skip per-project boilerplate

## Summary

There is no way to get the benefit of sverklo's memory import without running the full `sverklo init` kitchen sink per project. Users who want a global-instructions workflow (one-time machine setup, then per-project: just register) are stuck.

`importExistingMemories()` (scans CLAUDE.md, ADRs, .cursorrules, etc.) is called **only** from `initProject()`. There's no CLI subcommand for it, the Indexer doesn't call it, and `sverklo register` doesn't call it. So there is no manual workaro

[Read the thread](https://github.com/sverklo/sverklo/issues/72) · 2026-05-25 · closed · external user · 3 comments

### MCP tool names double-prefixed (sverklo_sverklo_*) when server registered under 'sverklo' key

## Summary

All MCP tools are named with a `sverklo_` prefix (e.g. `sverklo_impact`, `sverklo_lookup`, `sverklo_search`). This collides with the MCP client convention of prefixing tools with the server name, producing `sverklo_sverklo_impact` when the server is registered under key `"sverklo"`.

## Root Cause

The tool definitions in `src/server/tools/*.ts` all carry a `sverklo_` prefix in their `name:` field:

```ts
// src/server/tools/impact.ts
export const impactTool = {
  name: "sverklo_impa

[Read the thread](https://github.com/sverklo/sverklo/issues/71) · 2026-05-25 · closed · external user · 2 comments

### v0.25.1: Ollama reindex still stores 384d vectors despite 1024d config; Windows index lock may still persist after Claude Code exit

# v0.25.1: Ollama reindex still stores 384d vectors despite 1024d config; Windows index lock may still persist after Claude Code exit

Thanks for the fixes in the recent release. The MCP-related errors I previously reported appear to be resolved in `sverklo v0.25.1`: `doctor` now reports a successful MCP handshake, tools/list, and tools/call round-trip.

However, I’m still seeing one major indexing/provider issue after a full reindex: the project is configured for Ollama with 1024-dimensional em

[Read the thread](https://github.com/sverklo/sverklo/issues/66) · 2026-05-23 · closed · external user · 6 comments

### `reindex --force` reports success after EBUSY and appears to reuse stale index on Windows

# `reindex --force` reports success after EBUSY and appears to reuse stale index on Windows

Thanks for the continued work on sverklo and the recent Windows/MCP fixes. While testing v0.23.1 on Windows with MCP clients, I hit a lock-handling issue where `reindex --force` logs EBUSY errors, appears not to rebuild the index, but still exits with a success-style “Done” message.

## Summary

On Windows, if the MCP server or a related process holds `index.db` open, `sverklo reindex --force --timing` f

[Read the thread](https://github.com/sverklo/sverklo/issues/58) · 2026-05-22 · closed · external user · 1 comment

### MCP still failing on Windows in v0.23.0

# MCP still failing on Windows in v0.23.0

Thanks for the continued work on sverklo and for the quick turnaround on the recent Windows/MCP fixes. I’ve been testing sverklo in a real Windows project with a moderately large documentation tree and multiple CLI integrations, and I’m filing this as a focused follow-up because MCP still appears to fail on v0.23.0.

## Summary

Despite the fixes in v0.22.2 and v0.23.0 for the Windows `spawn EINVAL` issue in #47, MCP integration still fails for me on Wi

[Read the thread](https://github.com/sverklo/sverklo/issues/53) · 2026-05-21 · closed · external user · 3 comments

### Bug: sverklo doctor reports MCP handshake/tools failures even though Claude Code can reconnect to sverklo

## What happened?

On Windows, `sverklo doctor` reports that the MCP handshake, `tools/list`, and `tools/call` checks fail, saying Claude Code would see zero tools / calls would hang or error.

However, when I start Claude Code in the same project and run `/mcp`, Claude Code reports that it successfully reconnected to `sverklo`.

I also reconnected from Claude Code and then reran `sverklo doctor` to be safe, but `sverklo doctor` still reported the same MCP failures.

This looks like either:

- 

[Read the thread](https://github.com/sverklo/sverklo/issues/47) · 2026-05-19 · closed · external user · 3 comments

### MCP tool surface: sverklo_recall hinted but not available

### What happened?

The `sverklo_status` tool output includes a hint listing `sverklo_recall` as the recommended way to retrieve saved design decisions:

```
_Hints (intent: onboarding)_
- Try `sverklo_recall query:"architecture"` for any saved design decisions.
```

However, `sverklo_recall` is **not actually exposed** as an available tool on the MCP server. The only Sverklo tools available are:
- `sverklo_status`
- `sverklo_overview`
- `sverklo_search`
- `sverklo_lookup`
- `sverklo_refs`
- `sv

[Read the thread](https://github.com/sverklo/sverklo/issues/36) · 2026-05-13 · closed · external user · 1 comment

### Distribute sverklo plugins via Claude Code's plugin marketplace

### Problem or motivation

Sverklo ships a first-party Claude Skill package (`skill/`, `sverklo-skill.zip`), but there's no standard way for users to discover, share, or install community extensions built on top of sverklo. Claude Code offers a [native plugin marketplace protocol](https://code.claude.com/docs/en/plugin-marketplaces) that could serve as a zero-infrastructure distribution channel for sverklo plugins.

### Proposed solution

Create a **sverklo plugin marketplace** files following t

[Read the thread](https://github.com/sverklo/sverklo/issues/23) · 2026-05-01 · closed · external user · 1 comment

## Most recent

### Add setup docs / `sverklo init` support for Codex and GitHub Copilot CLI

Hi! First off, thanks for building Sverklo.

I have successfully enabled Sverklo with Claude Code, and it works well there. I would like to understand what is needed to enable the same workflow for OpenAI Codex and GitHub Copilot CLI.

From what I can tell:

- Sverklo already works as an MCP server.
- `sverklo init` currently auto-detects and configures clients like Claude Code, Cursor, Windsurf, and Zed.
- Codex supports MCP servers through `~/.codex/config.toml` or project-level `.codex/config

[Read the thread](https://github.com/sverklo/sverklo/issues/50) · 2026-05-19 · closed · external user · 1 comment

### Improve "Not connected" error with actionable hint

## Problem

When the MCP server is running but the project has not been registered/indexed, calling `sverklo_status` returns only:

```
Not connected
```

This is misleading — the MCP server **is** connected, but there's no index for the current project. The user is left guessing whether the server is down, the config is wrong, or something else is broken.

## Suggestion

Add a hint when the project directory has no registered index. Something like:

```
Not connected — no index found for this p

[Read the thread](https://github.com/sverklo/sverklo/issues/39) · 2026-05-14 · closed · external user · 1 comment

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