pod
Other formats agents might prefer:
markdownjsonllms.txt

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

Reported issues for Repowise

Pod holds 17 of 33 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 Repowise.

Most discussed

Security as an intelligence layer, not a byproduct — scoping check before we build

Where this comes from

We run repowise across a workspace of TypeScript/Next.js repos. Digging into the security surface, we found the plumbing is genuinely good and the analysis behind it is thin. Before we spend weeks on it, we would like to know which parts of the following you would take, and which you would rather we keep in a fork.

What already exists (and works well)

  • SecurityScanner + the security_findings table, idempotent across re-runs via the `(repository_id, file_path

Read the thread · 2026-08-27 · open · outside contributor · 4 comments

[Bug] Write with AI documentation page 404

Describe the Bug

In workspace mode, the Write with AI action for a documentation page fails with 404 Page not found.

The page itself can be opened successfully in the frontend, but regenerating it fails because the regenerate request does not include repo_id. In workspace mode, repo_id is required to route the database session to the correct repository database.

A manual regenerate request with repo_id added succeeds with 202 Accepted.

Steps to Reproduce

  1. Start Repowis

Read the thread · 2026-08-17 · open · outside contributor · 3 comments

[Bug] init writes project-local .mcp.json / .vscode files with no opt-out, and reformats unrelated entries in a tracked file

Describe the Bug

repowise init writes project-local editor files — including .mcp.json, which is a tracked file in many repos — and there is no flag that opts out of it. --no-editor-setup and REPOWISE_SKIP_EDITOR_SETUP=1 both cover only machine-wide registration; --no-claude-md and --no-codex cover their own files. Nothing covers .mcp.json or .vscode/.

Two distinct problems:

  1. Unrequested writes to a tracked file. .mcp.json is modified and .vscode/mcp.json + `.

Read the thread · 2026-08-15 · open · external user · 6 comments

get_answer never passes the configured reasoning mode to the provider, so REPOWISE_REASONING=off has no effect on synthesis

Summary

REPOWISE_REASONING=off does not reach get_answer synthesis. The resolved mode is dropped at the call site, so the provider default "auto" always wins and a thinking-capable model is free to reason. Because synthesis is capped at 1024 output tokens, a model that reasons at any length can consume the whole budget and return no prose, leaving only retrieval hits and this note:

DEGRADED: the model used its entire 1024-token budget without emitting an answer
(provider=ollama, m

[Read the thread](https://github.com/repowise-dev/repowise/issues/1560) · 2026-08-14 · closed · external user · 5 comments

### [Bug] `get_answer` retrieval succeeds but synthesis always times out (~30s) — returns empty answer with `degraded: synthesis-failed`

Below is an LLM-generated bug report after several fails of attempting to utilize Repowise MCP `get_answer` tool:

`get_answer` consistently fails during **answer synthesis** with `TimeoutError` (wall clock ~30–31s). **Retrieval appears healthy** (relevant `fallback_targets`, snippets, `key_symbols`), but `answer` is always empty:

- `confidence: "low"`
- `degraded: "synthesis-failed"`
- note: `DEGRADED: LLM synthesis failed (TimeoutError). Read the listed files to answer.`

Narrowing the questi

[Read the thread](https://github.com/repowise-dev/repowise/issues/1119) · 2026-07-27 · closed · external user · 5 comments

### [Bug] init always writes project-local .mcp.json / .vscode/mcp.json, even with --no-editor-setup

## Describe the Bug

`repowise init` always merges a `repowise` entry into the repo-root `.mcp.json` and writes `.vscode/mcp.json`, with no way to opt out. `--index-only`, all `--no-*` flags, `REPOWISE_SKIP_EDITOR_SETUP=1`, and even the new `--no-editor-setup` (#1086) don't stop it — that flag only gates the machine-wide `register_editor_clients` path, while `write_editor_project_files()` still runs unconditionally in `init_cmd/command.py`.

This breaks running `init` as an automated setup step 

[Read the thread](https://github.com/repowise-dev/repowise/issues/1117) · 2026-07-27 · closed · external user · 4 comments

### Workspace mode: Chat tools (`get_overview` / `search_codebase`) fail with `LookupError: Repository not found` even for the primary repo

## Body

### Environment

- repowise version: `0.34.0`
- Install method: `pip install "repowise[litellm]"`
- OS: CentOS Stream 9 (RHEL 9 family)
- Deployment: `repowise serve --host 0.0.0.0 --port 7337 --no-ui`, workspace mode with 2 repos
- LLM provider: `litellm`, model `openai/MiniMax-M3` (confirmed unrelated to this bug — see below)
- Embedder: `mock`

### Description

In a multi-repo workspace, the Chat UI can successfully call the LLM and stream a response, but any tool call that resolves 

[Read the thread](https://github.com/repowise-dev/repowise/issues/970) · 2026-07-21 · closed · external user · 3 comments

### get_health: "Repository not found" for any workspace alias that differs from the directory basename

### Summary

In workspace mode, `get_health` fails with `Repository not found: <alias>` for any repo whose **workspace alias differs from its directory basename** — even though `list_repos` advertises that exact alias and every other workspace tool (`get_answer`, `get_dead_code`, `search_codebase`) accepts it.

Version: **repowise 0.31.0** (workspace mode, stdio transport).

### Reproduce

Register two repos in a workspace where the alias does not equal the folder name:

| alias | directory | `g

[Read the thread](https://github.com/repowise-dev/repowise/issues/855) · 2026-07-16 · closed · external user · 3 comments

## Most recent

### [Feature] prevent premature timeout during long-running distill/cmake builds

## Problem

When executing long-running compilation commands (such as running cmake via distill on large repositories for the first time), the agent incorrectly assumes the process is stuck. As a result, it prematurely terminates the execution before the build can finish.

## Proposed Solution
To prevent the agent from prematurely terminating long-running compilation processes, we propose introducing a tracking mechanism via a unique reference ID and an Model Context Protocol (MCP) command.

## 

[Read the thread](https://github.com/repowise-dev/repowise/issues/1781) · 2026-08-21 · open · external user · 1 comment

### [Bug] --host makes the MCP server unreachable — 421 Misdirected Request

## Describe the Bug

`repowise mcp --transport streamable-http --host <non-loopback>` (also reproduces on
`--transport sse`) binds successfully and logs the correct address, but every client request is
rejected with `421 Misdirected Request` before reaching any tool. The server logs `Invalid Host
header: ...`. This happens for any non-default `--host` value (a LAN IP, a hostname, or
`0.0.0.0`) — the connection cannot be used at all, regardless of what `--host` is actually set to.

## Steps to Re

[Read the thread](https://github.com/repowise-dev/repowise/issues/1736) · 2026-08-19 · closed · outside contributor · 0 comments

### Semantic search silently returns zero on first query: cold vector-search path exceeds 8s _safe_vector timeout and the exception is swallowed

### Summary
`repowise search "<prose>" --mode semantic` returns **zero results** for the first query in a fresh process, even when the vector index is healthy (reindex OK, doctor drift 0.0%). The vector leg silently degrades to FTS/symbol-only. Warm follow-up queries return results instantly. This mirrors the failure mode described in #1495 (silent degradation, exit 0, no error) but the root cause here is a **cold-path timeout**, not the ollama build failure.

### Version
- repowise 0.43.0 (inst

[Read the thread](https://github.com/repowise-dev/repowise/issues/1678) · 2026-08-17 · closed · external user · 2 comments

### [Feature] claude_cli provider: generate pages with a Claude Code subscription instead of an API key

## Problem

Repowise can already run page generation off a coding-agent subscription rather than a metered API key — `codex_cli` does it for Codex, `opencode` for OpenCode. There is no equivalent for Claude Code, even though `anthropic` is a first-class provider.

So a user with a Claude subscription (Pro / Max / Team / Enterprise) has no keyless path. They see:

No provider configured. Use --provider, set REPOWISE_PROVIDER, or set ANTHROPIC_API_KEY / ... Use REPOWISE_PROVIDER=codex_cli to u

Read the thread · 2026-08-13 · closed · outside contributor · 1 comment

Critical: /api/repos/{id}/file-content reads arbitrary repo files incl. .repowise/.env (API key exfiltration)

Summary

GET /api/repos/{repo_id}/file-content?file_path=... returns the raw contents of any file under the registered repo — there is no restriction to source files, tracked files, or indexed paths. .repowise/.env (which stores the user's LLM provider API keys) and .git/config are freely readable. Combined with #1391 the read is unauthenticated on any network-exposed server; a caller can even register an arbitrary on-disk git repo via POST /api/repos and read inside it.

Affec

Read the thread · 2026-08-10 · closed · outside contributor · 1 comment

Critical: auth fails open when binding to 0.0.0.0 via --host — REPOWISE_HOST never reflects the bind address

Summary

verify_api_key decides "loopback vs network-exposed" from the REPOWISE_HOST environment variable (default 127.0.0.1), not from the address the server is actually bound to. The documented CLI flag repowise serve --host 0.0.0.0 never sets REPOWISE_HOST, so starting the server network-exposed without a key keeps every endpoint unauthenticated, and the intended fail-closed branch is dead code.

Affected code

  • packages/server/src/repowise/server/deps.py:26 — `_REP

Read the thread · 2026-08-10 · closed · outside contributor · 1 comment

v0.37.0 get_risk returns hotspot_score=0, primary_owner=null despite data in wiki.db — column name mismatch

Version: 0.37.0 Repo type: Azure DevOps, .NET/C# monorepo

Issue: get_risk MCP tool returns hotspot_score=0, primary_owner=null, co_change_partners=[], trend="unknown", and risk_summary="no git metadata available" for files with rich behavioral data in wiki.db.

Root cause (confirmed via schema inspection): The MCP layer queries legacy column names that no longer exist in the v0.37.0 git_metadata table:

MCP queries Actual column name hotspot_score temporal_hotspot_score primary_owner primary_ow

Read the thread · 2026-08-03 · open · external user · 2 comments

OpenAI embedder ignores REPOWISE_EMBEDDING_DIMS for models outside its built-in table

Summary

The OpenAI embedder derives its output width from a three-entry table of OpenAI's own models (text-embedding-3-small, text-embedding-3-large, text-embedding-ada-002) and defaults to 1536 for anything else. It never reads the REPOWISE_EMBEDDING_DIMS setting.

So when Repowise is pointed at an OpenAI-compatible endpoint — a self-hosted or third-party model whose width is not 1536 — the vector store is silently created at 1536 while the endpoint returns vectors of a differ

Read the thread · 2026-08-02 · closed · outside contributor · 0 comments

Eleven implementations of "is this path a test?" disagree on 5 of 11 paths, and none reads the is_test the ingestion already stored

Nineteen places decide "is this path a test?" from the path string, under six different names, over seventeen separate pattern definitions. They disagree with each other, three of them classify production code as tests, and sixteen of them re-derive an answer the ingestion already computed and stored.

This is not a tidiness issue: three call sites return wrong answers for real paths, and two of the disagreements change what the health engine and the search rank.

Version: 0.36.0, verified a

Read the thread · 2026-07-26 · closed · external user · 1 comment

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