Reported issues for Gerrit Code Review

Pod holds 21 of 37 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 Gerrit Code Review.

Most discussed

Publish MCP registry entry

Context

Discoverability through the official MCP registry. Frame Phase 5.

What to do

Author server.json (name team.gaijin/go-gerrit-mcp, package entries for the binary/OCI distributions, env variable declarations) and publish via the registry's publisher tooling
Complete the one-time domain-namespace verification for gaijin.team (DNS TXT or HTTP challenge) before publishing

Acceptance criteria

Registry entry resolves and lists the current release
Declared env var

Read the thread · 2026-07-10 · closed · 3 comments

Verify transitions on a sandbox change

Context

Frame Phase 4 verification gate.

What to do

On a sandbox change: set and delete a vote, toggle WIP/ready, abandon and restore; attempt a blocked submit and confirm the reported reason
Confirm --groups transition alone is self-sufficient (bundled get_change present)

Acceptance criteria

All five actions verified live; blocked submit reports Gerrit's reason
Standalone transition group works without read

Estimate: ~0.5h Artifact: confirmation notes

Read the thread · 2026-07-10 · closed · 2 comments

Validate cold-start setup from README

Context

Frame Phase 5 verification gate — the five-minute test.

What to do

On a machine without the repo: follow the README only, from install to a working read-group server in an MCP client against a real Gerrit
Time it; note every point of friction; file issues for anything that breaks the five-minute budget

Acceptance criteria

Working server from README alone in under five minutes
Friction points filed as issues

Estimate: ~1h Artifact: validation notes +

Read the thread · 2026-07-10 · closed · 1 comment

Verify comment flow against live Gerrit

Context

Frame Phase 3 verification gate.

What to do

On a live change: post a new inline comment, reply into an existing thread, resolve and unresolve it; confirm threading and states in the Gerrit UI
Attempt a comment on a foreign change with the restriction on; confirm local refusal

Acceptance criteria

Threaded reply lands threaded; resolution state matches intent
Foreign-change attempt refused without leaving the process

Estimate: ~0.5h Artifact: confirmatio

Read the thread · 2026-07-10 · closed · 1 comment

Verify read group and scoping against live Gerrit

Context

Frame Phase 2 verification gate.

What to do

Exercise all five read tools against a live instance through an MCP client
With --projects set, attempt to escape the allowlist via crafted queries and direct fetches; confirm containment
File issues for gaps before Phase 3 starts

Acceptance criteria

All five tools return correct data live
Scoping escape attempts fail

Estimate: ~0.5h Artifact: confirmation notes; follow-up issues if any

References

Read the thread · 2026-07-10 · closed · 1 comment

Verify tracer bullet against live Gerrit

Context

Frame Phase 1 verification gate — proof the full stack holds before depth is added.

What to do

Register the binary in a real MCP client against a live Gerrit instance; call get_change on a known change
Exercise the failure paths: wrong token, nonexistent change
Record any mismatch between expected and actual behavior as issues before Phase 2 starts

Acceptance criteria

Live get_change returns correct llmxml for a real change
Startup with invalid credential

Read the thread · 2026-07-10 · closed · 1 comment

Document review notifications in the README

Context

Operators learn the feature exists, how to enable it, and its research-preview caveats from the README. Frame Phase 4.

What to do

Add the feature section: what it does, the flag family rows in the configuration table, subscription semantics (session-scoped, trail-free, auto-unsubscribe on terminal states)
Document channel enablement: claude --channels for allowlisted plugins, --dangerously-load-development-channels server:<name> for a bare server entry during the research

Read the thread · 2026-07-13 · closed · 0 comments

Harden the poller: failures, lost access, shutdown

Context

The poller is the codebase's first long-lived concurrent component; its failure behavior is part of the feature's contract. Frame Phase 4.

What to do

Poll failure policy: log to stderr, keep subscriptions, retry next tick; repeated failures never kill the loop or the server
A subscribed change that becomes inaccessible (deleted, scope lost, permission revoked) ends its subscription with a notification naming the reason
Clean shutdown: context cancellation mid-tick exits prom

Read the thread · 2026-07-13 · closed · 0 comments

Most recent

Finalize model-facing prompts for subscriptions

Context

The feature's behavior is prompt-driven: the model subscribes because the instructions and tool descriptions tell it when and why. Frame Phase 3, following the first-contact prompt work.

What to do

Write the full conditional instructions section: subscribe after pushing a reviewable change or when awaiting a review outcome; what arrives and in which vocabulary; what auto-unsubscription means; re-subscribe after a session restart
Finalize both tools' descriptions and input sche

Read the thread · 2026-07-13 · closed · 0 comments

Apply the filter chain to extracted activity

Context

Filters run between extraction and rendering so excluded activity never reaches the model. Frame Phase 3, ADR 2.2.

What to do

Apply, per extracted event: self-authorship (dropped unless include-own), excluded accounts (match username or numeric ID), content patterns (match against message and comment text)
A delta filtered to empty produces no notification at all
Bare votes pass the same account filters; status transitions are never content-filtered

Acceptance criteria

Read the thread · 2026-07-13 · closed · 0 comments

Add filter configuration: include-own, account and pattern exclusions

Context

Noise control is operator configuration, not server heuristics: own activity is skipped by default, and exclusions name accounts or content patterns. Frame Phase 3, ADR 2.2.

What to do

Add --review-notifications-include-own (boolean, default off), --review-notifications-exclude-accounts (comma-separated usernames or numeric account IDs), and --review-notifications-exclude-patterns (comma-separated regular expressions) with mirrors
Compile patterns at load; an invalid reg

Read the thread · 2026-07-13 · closed · 0 comments

End subscriptions automatically on terminal states

Context

A merged or abandoned change almost never needs further watching; the model must learn the subscription ended rather than infer it from silence. Frame Phase 2, ADR 2.2.

What to do

On detecting a transition to merged or abandoned, emit a final notification that carries the transition, states that the subscription ended automatically, and that no further notifications will arrive
Remove the change from the store after the final notification
When the terminal transition and oth

Read the thread · 2026-07-13 · closed · 0 comments

Add unsubscribe_change and render self-sufficient payloads

Context

Notifications must be self-sufficient: the payload carries the activity itself in the vocabulary the model already reads, so nothing needs fetching afterwards. Frame Phase 2, ADR 2.1.

What to do

Add the unsubscribe_change tool: removes the subscription, acknowledges in llmxml, tolerates unsubscribing a change that is not subscribed with a clear message
Render each delta as a review_activity llmxml payload composing the existing element vocabulary — change messages, votes,

Read the thread · 2026-07-13 · closed · 0 comments

Extract per-kind activity deltas with cursors

Context

The bare updated-movement event becomes real review activity: which messages, votes, comment threads, and status transitions are new since the last tick. Frame Phase 2, ADR 2.2.

What to do

Grow the cursor into per-kind high-water marks so each activity kind is reported at most once
Extract from the detailed change fetch and the comments listing: new change messages (author, date, tag, revision number), new votes (per-voter approval dates newer than the cursor, label and value)

Read the thread · 2026-07-13 · closed · 0 comments

Add subscribe_change tool and conditional channel wiring

Context

With the feature enabled the server declares the claude/channel capability, registers the subscription tools, and teaches the model when to subscribe; disabled, the server is byte-identical to today. Frame Phase 1, ADR 2.1, glossary entries Review notifications and Channel.

What to do

Add the subscribe_change tool: accepts any change identifier, validates existence and project scope via the existing change fetch, stores the subscription, returns an llmxml acknowledgement

Read the thread · 2026-07-13 · closed · 0 comments

Build wrapping transport and channel emission seam

Context

The pinned Go SDK has no public generic notification sender, so channel events are written as ID-less JSON-RPC notifications through a transport wrapper that captures the connection (Connection.Write is documented concurrency-safe). Frame Phase 1, ADR 2.1.

What to do

Wrap the stdio transport so the captured connection is available to the notification emitter after Server.Run connects
Implement the emitter: method notifications/claude/channel, params content (llmxml pay

Read the thread · 2026-07-13 · closed · 0 comments

Build subscription store and polling loop

Context

Subscriptions are per-session, in-memory, and trail-free; the poller is the codebase's first background goroutine. Frame Phase 1, ADR 2.2, glossary entry Subscription.

What to do

Create the notifications package with a concurrency-safe subscription store keyed by change number, each entry carrying a cursor (initially the last-seen updated timestamp)
Implement the polling loop: one batched change:A OR change:B query per tick over subscribed changes; skip the tick entirely

Read the thread · 2026-07-13 · closed · 0 comments

Add review-notifications enable and poll-interval configuration

Context

The feature is gated by a dedicated flag family with environment mirrors — deliberately not a capability group. Frame Phase 1, glossary entry Review notifications.

What to do

Add --review-notifications (boolean enable, default off) and --review-notifications-poll-interval (default 60s) as behavior flags with GERRIT_MCP_REVIEW_NOTIFICATIONS* mirrors
Follow the established precedence (flag over mirror over default) and aggregated-error reporting
Reject non-positive or

Read the thread · 2026-07-13 · closed · 0 comments

Write learning tests for SDK capability override and raw notification write

Context

The channels contract rests on two SDK assumptions research could not fully verify: overriding ServerOptions.Capabilities with an Experimental entry must not lose the inferred tools capability, and an ID-less jsonrpc.Request written through a wrapped mcp.Connection must be framed correctly alongside concurrent SDK traffic. Frame Phase 1, ADR 2.1.

What to do

Write learning tests probing both behaviors against the pinned Go SDK, using an in-process client (stub or SDK clie

Read the thread · 2026-07-13 · closed · 0 comments

thread states must match the change screen, which shatters threads on range/order quirks

get_change_comments reconstructs threads per Gerrit's server-side CommentThreads semantics (change-wide id pooling, chronological tails). The change screen — the thing users actually look at — computes different threads via polygerrit's comment-util.ts, and three of its quirks interact:

sanitiseRanges copies a parent's range onto rangeless replies in payload array order; replies that precede their parent in the array stay rangeless,
the comment sort orders rangeless before range

Read the thread · 2026-07-13 · closed · 0 comments

get_change_comments is blind to the caller's draft comments

On a change where the calling account has unpublished draft comments, the thread states reported by get_change_comments diverge from what that user sees in the Gerrit UI: polygerrit merges the viewer's own drafts into thread state client-side (an unresolved draft reply reopens a thread; a new draft starts an unresolved thread), while the REST /comments endpoint returns published comments only.

Observed in the field as an agent reporting "0 unresolved threads — nothing awaiting response" whi

Read the thread · 2026-07-13 · closed · 0 comments

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