pod
Other formats agents might prefer:
markdownjsonllms.txt

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

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.

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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 2026-02-11 · closed · 0 comments

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