# Reported issues for codereviewbuddy

Pod holds 19 of 55 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 [codereviewbuddy](/mcp/codereviewbuddy).

## Most discussed

### bug: MCP server becomes unresponsive after multiple rapid tool calls

## Summary

The MCP server stops responding after a sequence of rapid tool calls (e.g. `resolve_stale_comments` → `reply_to_comment` → `resolve_comment` → `resolve_comment` → `request_rereview`). Once the server enters this state, the only recovery is a full client restart — reconnecting to the server alone does not help.

## Reproduction

1. Run a PR review workflow that makes several tool calls in quick succession
2. After ~4-6 sequential calls, the server stops responding
3. Subsequent tool c

[Read the thread](https://github.com/detailobsessed/codereviewbuddy/issues/65) · 2026-02-09 · closed · 13 comments

### Server hangs when roots/list request returns error from Windsurf

## Bug

When CRB's MCP server issues a `roots/list` sub-request during a tool call, and Windsurf responds with `{"code":-32603,"message":"no roots handler configured"}`, the server hangs indefinitely — never responding to the original tool call.

Windsurf does not support `roots/list`. The server should handle this error gracefully instead of deadlocking.

## Evidence

From `~/.codereviewbuddy/io_tap.jsonl` on 2026-03-16:

```
15:45:30 — PID 38456 receives summarize_review_status (rpc_id 26)
15:

[Read the thread](https://github.com/detailobsessed/codereviewbuddy/issues/234) · 2026-03-16 · closed · 2 comments

### feat: add PR review completion checklist to agent instructions

## Problem

During review passes, agents sometimes skip housekeeping steps like:
- Updating PR descriptions with meaningful summaries
- Adding `Fixes #N` / `Closes #N` for issues addressed by each PR in the stack
- Verifying all PRs in the stack have correct issue linkage

This leads to issues not auto-closing on merge and PR descriptions being boilerplate.

## Proposed solution

Add a "PR review completion checklist" that agents must verify before considering a review pass complete:

1. **PR de

[Read the thread](https://github.com/detailobsessed/codereviewbuddy/issues/114) · 2026-02-11 · closed · 2 comments

### feat: add per-reviewer configuration system

## Summary

Add a configuration system that allows teams to customize codereviewbuddy behavior per reviewer. Configuration should be committed to the repo (e.g. `.codereviewbuddy.toml` or similar) so it can be shared across a team.

## Motivation

Currently, reviewer behavior is hardcoded in the adapter classes. For example, even though the server is designed to skip resolving Devin bug-level comments, agents still resolve them via `resolve_comment`. A configuration system would give teams expli

[Read the thread](https://github.com/detailobsessed/codereviewbuddy/issues/64) · 2026-02-09 · closed · 2 comments

### Investigate MCP server process death during list_review_comments (2026-03-15)

## Context

On 2026-03-15, the CRB MCP server (PID 26517) received a `list_review_comments` call (rpc_id 24) and died without writing a response back to stdout. Windsurf displayed "Step was canceled by user."

This is tracked as a Windsurf-side bug in [inofficial-windsurf-issues](<https://github.com/ichoosetoaccept/inofficial-windsurf-issues>) (`drafts/parallel-mcp-write-cancellation.md`), but there's a **server-side component** worth investigating: the CRB server errored internally in 8ms and t

[Read the thread](https://github.com/detailobsessed/codereviewbuddy/issues/233) · 2026-03-15 · closed · 1 comment

### Two concurrent server processes share stdout pipe, causing silent response drops

## Summary

A new failure mode distinct from #65: the MCP server's tool call response is **silently never delivered** to the client, even though the server completed the tool successfully. Unlike #65 (gh CLI subprocess hangs), the server here either finishes or gets killed — but the response bytes never reach the client.

## Evidence from io_tap.jsonl

Analysis of `~/.codereviewbuddy/io_tap.jsonl` revealed **two interleaved ping ID sequences** writing to the same stdout pipe simultaneously:

```

[Read the thread](https://github.com/detailobsessed/codereviewbuddy/issues/211) · 2026-03-03 · closed · 1 comment

### bug: list_review_comments misses inline threads from Greptile reviews

## Problem

`list_review_comments` and `triage_review_comments` returned only 1 inline thread for PR #178, but Greptile posted at least 3 inline comments (visible in the GitHub UI with '4 threads hidden'). Two inline comments were completely absent from the API response:

1. **install.py line 168**: 'Version check only inspects stdout' — suggests also checking stderr
2. **install.py lines 264-265**: 'Cursor deeplink includes empty env in payload' — suggests `exclude_defaults=True`

Only the walr

[Read the thread](https://github.com/detailobsessed/codereviewbuddy/issues/180) · 2026-02-18 · closed · 1 comment

### Add subprocess-level timing to gh CLI wrapper for issue #65 diagnostics

## Problem

Our issue #65 observability analysis (tool_calls.jsonl + io_tap.jsonl) confirmed that MCP transport is healthy during hangs — the bottleneck is in tool execution. Two concurrent `list_review_comments` calls hung for **503 seconds** while pings succeeded every 30s.

However, we can't yet distinguish between:
- Time spent in our Python orchestration code (building args, processing results)
- Time spent waiting for the `gh` CLI subprocess to return

## Solution

Add timing instrumentati

[Read the thread](https://github.com/detailobsessed/codereviewbuddy/issues/137) · 2026-02-13 · closed · 1 comment

## Most recent

### feat: add tool timeouts to prevent gh CLI hangs

FastMCP 3.0 adds tool timeouts. We should configure timeouts on our tools to prevent indefinite hangs when `gh` CLI calls stall (network issues, GitHub API outages).

**What's available:**
- Tool-level timeout configuration
- Sync functions auto-dispatch to threadpool

**Value:** Prevents agent sessions from hanging when GitHub API is slow or unresponsive. Our `gh` CLI calls are the primary bottleneck.

Ref: https://github.com/PrefectHQ/fastmcp/releases/tag/v3.0.0

[Read the thread](https://github.com/detailobsessed/codereviewbuddy/issues/190) · 2026-02-19 · open · 0 comments

### feat: explore session-scoped component visibility for role-based tool access

FastMCP 3.0 introduces session-specific visibility control via `ctx.enable_components()` / `ctx.disable_components()`. This could let us adapt available tools per session — e.g. hide write operations (resolve, reply) until the agent explicitly opts in, or scope tools based on configuration.

**What's available:**
- `ctx.enable_components()` / `ctx.disable_components()` per session
- Granular authorization on individual components with async auth checks

**Potential use cases:**
- Progressive dis

[Read the thread](https://github.com/detailobsessed/codereviewbuddy/issues/189) · 2026-02-19 · open · 0 comments

### feat: evaluate component versioning for backward-compatible tool evolution

FastMCP 3.0 supports component versioning — serve `@tool(version="2.0")` alongside older versions from one codebase. This could help us evolve tool signatures without breaking existing agent workflows.

**What's available:**
- `@tool(version="2.0")` decorator parameter
- `VersionFilter` transform for automatic highest-version selection
- Clients can request specific versions

**Value:** Would let us iterate on tool signatures (e.g. adding structured return types, changing parameters) without bre

[Read the thread](https://github.com/detailobsessed/codereviewbuddy/issues/188) · 2026-02-19 · open · 0 comments

### feat: adopt OpenTelemetry tracing from FastMCP v3

FastMCP 3.0 adds OpenTelemetry tracing with MCP semantic conventions. We should instrument codereviewbuddy to provide observability into tool calls, gh CLI latency, and error rates.

**What's available:**
- Built-in OpenTelemetry tracing support
- MCP semantic conventions for spans

**Value:** Would help diagnose slow tool calls, track gh CLI performance, and provide production observability.

Ref: https://github.com/PrefectHQ/fastmcp/releases/tag/v3.0.0

[Read the thread](https://github.com/detailobsessed/codereviewbuddy/issues/187) · 2026-02-19 · open · 0 comments

### Feature: auto-detect which AI reviewers are actually enabled on a repo

## Problem

The `/prreview` workflow currently triggers re-reviews for reviewers (e.g. Unblocked) that aren't even installed as GitHub Apps on the target repo. This wastes time and produces confusing no-ops.

The config (`show_config`) shows all reviewers as `enabled: true` regardless of whether their GitHub App is actually installed on the repository.

## Proposed solution

Add a tool or enhancement (e.g. `detect_active_reviewers`) that checks which AI reviewer GitHub Apps are actually installe

[Read the thread](https://github.com/detailobsessed/codereviewbuddy/issues/185) · 2026-02-18 · open · 0 comments

### Branch/repo auto-detection fails when MCP server cwd differs from repo

## Bug

When calling `summarize_review_status()` or `list_review_comments()` without explicitly passing the `repo` parameter, auto-detection fails because the MCP server process's working directory doesn't match the user's repository.

### Steps to reproduce

1. Open a repo (e.g. `detailobsessed/windsurf-teacher`) in Windsurf IDE
2. Check out a feature branch (e.g. `chore-fix-lychee-and-update-template`) with an open PR (#10)
3. Call `summarize_review_status()` with no arguments

### Expected

A

[Read the thread](https://github.com/detailobsessed/codereviewbuddy/issues/174) · 2026-02-17 · closed · 0 comments

### feat: Multi-root workspace support

Currently `CRB_WORKSPACE` only supports a single workspace directory. MCP roots can provide multiple roots, and some clients (e.g. multi-repo workspaces) may need the server to handle multiple projects.

**Proposal:**
- Accept comma-separated paths in `CRB_WORKSPACE`, or
- Use all MCP roots instead of just the first one
- Route `gh` commands to the correct root based on the `repo` parameter

Low priority — single-workspace covers the common case.

[Read the thread](https://github.com/detailobsessed/codereviewbuddy/issues/159) · 2026-02-16 · open · 0 comments

### Improve server instructions: add trigger phrases and first-review workflow

## Problem

The MCP server `instructions` field has a good 'Typical workflow after pushing a fix' section, but:

1. **No trigger guidance** — agents don't know this server is relevant when users say things like 'review my PR comments', 'what did reviewers say', 'do a PR review', 'check review feedback', etc. The instructions should list common trigger phrases so agents know to activate.

2. **Only covers post-fix workflow** — the current workflow assumes the agent already pushed a fix. There's n

[Read the thread](https://github.com/detailobsessed/codereviewbuddy/issues/135) · 2026-02-13 · closed · 1 comment

### bug: MCP tool calls can fail with missing fastmcp.server.tasks.routing

## Summary
In some MCP client sessions, codereviewbuddy tool calls fail immediately with:

No module named 'fastmcp.server.tasks.routing'

This blocks all codereviewbuddy tools (e.g. summarize_review_status, list_review_comments) even though the project dependency requires FastMCP >= 3.0.0rc1.

## What I observed
- MCP tool call errors:
  - summarize_review_status -> No module named fastmcp.server.tasks.routing
  - list_review_comments -> No module named fastmcp.server.tasks.routing
- In-repo en

[Read the thread](https://github.com/detailobsessed/codereviewbuddy/issues/132) · 2026-02-13 · closed · 0 comments

### feat: support dismissing PR-level reviews (PRR_) in resolve_comment

## Problem

`resolve_comment` only supports inline review threads (`PRRT_` prefix) via the `resolveReviewThread` GraphQL mutation. PR-level reviews (`PRR_` prefix) — like Devin's "found N potential issues" summaries — show as unresolved conversations in GitHub's UI but cannot be cleared by the agent.

`reply_to_comment` already handles all three thread types (`PRRT_`, `PRR_`, `IC_`), so `resolve_comment` has a gap.

## Proposed Solution

Add `dismissPullRequestReview` GraphQL mutation support fo

[Read the thread](https://github.com/detailobsessed/codereviewbuddy/issues/120) · 2026-02-11 · closed · 0 comments

### RFC: config-first, env-var-override pattern for MCP servers

## Context

We've built a `.codereviewbuddy.toml` config system that handles per-reviewer settings, PR description policies, self-improvement config, and more. But we still have one feature (`CODEREVIEWBUDDY_IO_TAP`) configured via env var only — and we missed capturing transport hang logs (#65) because nobody remembered to set it.

This exposed a broader question: **should MCP servers standardize on a configuration pattern?**

## Current state of MCP configuration

### The spec says nothing
The

[Read the thread](https://github.com/detailobsessed/codereviewbuddy/issues/118) · 2026-02-11 · closed · 0 comments

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