# Reported issues for gitcontribute

Pod holds 23 of 72 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 [gitcontribute](/mcp/gitcontribute).

## Most discussed

### [Feature] Publish a canonical MCP workflow for source audit and evidence handoff

## Motivation

GitContribute now has the individual pieces needed for a source-backed audit, but an agent still has to assemble the full route from several descriptions and documents. The intended workflow needs to distinguish offline corpus reads from explicit GitHub verification, treat missing coverage as unknown, perform duplicate checks before drafting, and preserve validation evidence for handoff.

This follows the completed routing/discoverability work in [#19](https://github.com/morluto/g

[Read the thread](https://github.com/morluto/gitcontribute/issues/236) · 2026-07-31 · closed · 2 comments

### [Feature] Let setup persist selected MCP toolsets

## Motivation

`gitcontribute mcp serve` accepts `--toolsets`, but `gitcontribute setup` does not expose or persist that selection. The setup command's current options contain no toolset flag ([`internal/cli/cli.go`](https://github.com/morluto/gitcontribute/blob/9c96943dd07fb32efc2b8a7ea8791444e3f2ddc2/internal/cli/cli.go#L122-L133)), while MCP serving does ([`internal/cli/cli.go`](https://github.com/morluto/gitcontribute/blob/9c96943dd07fb32efc2b8a7ea8791444e3f2ddc2/internal/cli/cli.go#L514-L51

[Read the thread](https://github.com/morluto/gitcontribute/issues/196) · 2026-07-26 · closed · 2 comments

### [Feature] Expose enabled and available MCP toolsets from the default catalog

## Motivation

GitContribute's small MCP catalogs are intentional, but the default catalog currently cannot explain whether a missing capability is unsupported or merely belongs to a disabled toolset. General routing instructions describe how to use the advertised tools; they do not expose the runtime version, selected toolsets, or other toolsets available in the installed build.

That ambiguity is especially visible with the default `contribute` registration: the source defines additional `code

[Read the thread](https://github.com/morluto/gitcontribute/issues/195) · 2026-07-26 · closed · 2 comments

### [Feature] Route the managed Codex skill across optional MCP toolsets

## Motivation

The managed Codex skill currently tells the client to discover GitContribute tools and fall back when no advertised tool fits. That works when the required tool is in the selected MCP catalog, but GitContribute intentionally separates specialized capabilities into optional toolsets.

With the default `contribute` registration, implementation inspection, base/candidate validation, external architecture research, authored-PR follow-up, and search diagnostics are not advertised. A cl

[Read the thread](https://github.com/morluto/gitcontribute/issues/194) · 2026-07-26 · closed · 2 comments

### [Feature] Add repeatable process validation with resource telemetry

## Motivation

A single validation run can show an exit status and bounded output, but it cannot establish whether a failure is flaky, caused by a readiness deadline, or associated with process/resource pressure.

This matters for MCP and cross-process workflows. In one real regression test, a readiness wait introduced an unrelated timing dependency. The useful proof was that malformed protocol input remained recoverable and the next tool call succeeded; the test did not need to wait for reposit

[Read the thread](https://github.com/morluto/gitcontribute/issues/115) · 2026-07-23 · closed · 2 comments

### [Bug] Exact-thread sync rejects documented thread selectors

## Description

The documented exact-thread selection shape for `github_sync_threads` is rejected by the MCP handler. This blocks the narrow refresh path and prevents dependent pull-request status hydration from obtaining current evidence.

Observed against `morluto/leantoken#167` on 2026-07-23:

```json
{
  "selection": "threads",
  "threads": [
    {"owner": "morluto", "repo": "leantoken", "kind": "pull_request", "number": 167}
  ]
}
```

The call returned:

```text
repository filters are not 

[Read the thread](https://github.com/morluto/gitcontribute/issues/112) · 2026-07-23 · closed · 2 comments

### [Feature] Verify expected symptoms in base/candidate validation

## Motivation

GitContribute can define one validation command, run it against base and candidate workspaces, and classify a failing-base/passing-candidate pair as `fixed`. That establishes that the command outcome changed, but not that the base failed for the reason named in the hypothesis or that the candidate changed the intended observable.

This distinction mattered in a recent Triton compiler investigation. The suspected bug was pipeline wait-buffer under-allocation. An initial regression 

[Read the thread](https://github.com/morluto/gitcontribute/issues/48) · 2026-07-20 · closed · 2 comments

### [Bug] Running MCP endpoint still serves obsolete review-thread GraphQL query

## Description

The GitContribute MCP endpoint currently available to a client still submits the obsolete PullRequestReviewComment.side field when synchronizing review_threads, even though the source fix for this schema mismatch was merged in #293.

This is distinct from the original source bug tracked by #283: #283 is closed as completed, and #293 removed the unsupported side and startSide selections. The observed failure indicates that the running or registered MCP artifact is stale, or that a

[Read the thread](https://github.com/morluto/gitcontribute/issues/297) · 2026-08-24 · closed · 1 comment

## Most recent

### [Bug] Managed skill directs issue audits to a removed MCP tool

## Description

The managed Codex skill tells agents to start exact issue audits with `workflow.prepare_issue_set` or `corpus.get_coverage`, but the unified MCP catalog deliberately filters `workflow.prepare_issue_set` out through `removedCompositeTools`.

This leaves a dead tool route in the generated guidance. An agent following the preferred exact-audit path gets a tool-not-found result and must infer a different composition from lower-level acquisition and corpus operations. The fallback nam

[Read the thread](https://github.com/morluto/gitcontribute/issues/292) · 2026-08-11 · closed · 1 comment

### [Feature] Let feedback indexing scope discovery by pull-request state

## Problem

`github.index_pull_request_feedback` currently enumerates pull requests with `state=all`. That deliberately preserves historical feedback, but it prevents an agent from requesting an index limited to the current open review surface.

The offline feedback search supports a `state` filter, but it runs only after acquisition. It cannot avoid listing, fetching, and persisting closed or merged pull requests.

This matters for workflows such as “review all open PRs and summarize feedback f

[Read the thread](https://github.com/morluto/gitcontribute/issues/285) · 2026-08-09 · closed · 1 comment

### [Feature] Make exact PR feedback sync scalable past 50 without caller-managed batches

## Motivation

An agent had an exact, already-discovered set of 62 open pull requests and needed their current review feedback. github.sync_pull_request_feedback is the documented exact-PR route, but its public contract and server validation reject more than 50 pull requests. The agent therefore has to partition the set itself.

That is not just cosmetic: submitting two legal exact-feedback batches concurrently produced a retryable persistence result for one item with database is locked. The job

[Read the thread](https://github.com/morluto/gitcontribute/issues/284) · 2026-08-09 · closed · 1 comment

### [Bug] Refresh review-thread feedback query after GitHub rejects PullRequestReviewComment.side

## Description

GitContribute MCP 1.0.0 cannot synchronize the review_threads channel against the current GitHub GraphQL schema. A feedback job that requested issue_comments, submitted_reviews, inline_comments, and review_threads completed with every affected item failed and this message:

    github graphql: Field 'side' doesn't exist on type 'PullRequestReviewComment'

This prevents both github.sync_pull_request_feedback and github.index_pull_request_feedback from producing usable feedback res

[Read the thread](https://github.com/morluto/gitcontribute/issues/283) · 2026-08-09 · closed · 1 comment

### [Bug] Make live-search artifact handoffs host-neutral and directly actionable

## Description

`github.search_threads` correctly persists a durable, digest-bound artifact and returns a native MCP `ResourceLink`. Its accompanying text instruction nevertheless requires the caller to translate the handoff into a host-specific operation:

```text
Ask the host to perform MCP `resources/read` with this server and the exact URI …; in Codex, call `read_mcp_resource`.
```

The resource is intentionally opaque and durable; that boundary should remain. The problem is that the public 

[Read the thread](https://github.com/morluto/gitcontribute/issues/280) · 2026-08-09 · closed · 1 comment

### [Bug] Make github.search_threads recoverable when callers use a repository reference

## Description

`github.search_threads` requires flat `owner` and `repo` inputs, while many neighboring GitContribute MCP tools accept a nested `repository` reference. A caller that follows the latter convention is rejected by SDK schema decoding before GitContribute can return its normal actionable `InvalidArgument` response.

This is a contract-discoverability problem rather than a request to make live search implicit or unbounded.

## Steps to Reproduce

1. Call `github.search_threads` with a

[Read the thread](https://github.com/morluto/gitcontribute/issues/279) · 2026-08-09 · closed · 1 comment

### [Bug] Keep explicit portfolio follow-ups bound to synchronized pull requests

## Description

After `github.sync_pull_request_portfolio(selection=explicit)` refreshes exact pull requests, its terminal typed follow-up can read a different global set from the corpus.

The job artifact preserves the synchronized references, but `portfolioReadFollowUpArguments` reduces an explicit selection to:

- `state=all`;
- `limit=len(references)`; and
- no exact pull-request filter.

`corpus.list_pull_request_portfolio` cannot accept exact references and orders all stored pull requests 

[Read the thread](https://github.com/morluto/gitcontribute/issues/276) · 2026-08-07 · closed · 0 comments

### [Feature] Scope authored pull-request portfolios to a repository

## Motivation

An agent inspecting recent pull requests for one repository cannot scope authored-PR portfolio discovery to that repository.

A real workflow asked for the authenticated user's recently closed pull requests in `Tencent-Hunyuan/UniRL` and invoked the then-advertised operation with:

```json
{
  "state": "closed",
  "limit": 20,
  "max_requests": 120,
  "updated_after": "2026-06-01T00:00:00Z"
}
```

The completed job spent the full 20-item bound on pull requests from `morluto/jacobi

[Read the thread](https://github.com/morluto/gitcontribute/issues/274) · 2026-08-07 · closed · 1 comment

### Publish GitContribute as a discoverable MCP server in the MCP Registry

## Current limitation

GitContribute exposes an MCP server through its npm distribution, but the repository does not currently publish MCP Registry metadata or an automated registry release path. Users therefore cannot discover the server through the official MCP Registry and may need to configure it manually.

## Desired outcome

Publish GitContribute under the registry name `io.github.morluto/gitcontribute`, with:

- an `mcpName` ownership marker in the npm package;
- a checked-in `server.json

[Read the thread](https://github.com/morluto/gitcontribute/issues/262) · 2026-08-01 · closed · 1 comment

### [Bug] Keep MCP registration aligned with the activated private runtime

## Description

An MCP-only installation can have a newer versioned private GitContribute runtime present while the coding-client registration still points to the previous runtime.

On the affected Linux installation, both private runtime paths for 0.15.0 and 0.16.0 existed, but the Codex MCP registration still pointed to the 0.15.0 executable. Restarting the computer therefore restarted the old runtime and continued to expose its older MCP tool catalog.

The observed state does not by itself pr

[Read the thread](https://github.com/morluto/gitcontribute/issues/260) · 2026-08-01 · closed · 0 comments

### [Feature] Make pull-request feedback routing explicit in MCP tool descriptions

## Motivation

The pull-request feedback workflow is difficult to discover from natural requests such as:

- “find all review comments by this author”;
- “show unresolved feedback across this repository”; or
- “audit the comments left by a review bot.”

The generic thread-search description advertises stored titles, bodies, and hydrated text, then recommends exact-thread hydration. It does not tell the caller that feedback-specific indexing and search are the canonical route, nor does it explain

[Read the thread](https://github.com/morluto/gitcontribute/issues/259) · 2026-08-01 · closed · 1 comment

### [Bug] Keep advertised MCP tools synchronized with the registered catalog

## Description

The current GitContribute source defines and registers repository-wide pull-request feedback tools, including:

- `github.index_pull_request_feedback`;
- `github.sync_pull_request_feedback`;
- `corpus.search_pull_request_feedback`;
- `github.sync_thread_facets`; and
- `corpus.get_thread_facets`.

However, the MCP tool catalog observed by a client exposed the older generic surface instead, including `corpus.search_threads` and `github_hydrate_threads`, while omitting the feedback-

[Read the thread](https://github.com/morluto/gitcontribute/issues/258) · 2026-08-01 · closed · 0 comments

### [Feature] Preserve exact identities and state in pull-request feedback search

## Motivation

Hydrated pull-request feedback is currently useful for full-text matching, but the corpus-facing results are still pull-request-level. A search match can report that a review facet contains the query while omitting the exact comment ID, inline review-thread identity, path/line anchor, and resolved/outdated state that a reviewer needs to act on.

This creates a second native-GitHub fallback even after the caller has correctly synchronized and hydrated the pull request. The caller m

[Read the thread](https://github.com/morluto/gitcontribute/issues/257) · 2026-08-01 · closed · 1 comment

### [Feature] Discover pull-request comments by author across a repository

## Motivation

GitContribute can discover an authored pull-request portfolio and can hydrate `pr_review_comments` for a bounded list of exact pull requests. However, it cannot directly answer a common repository-audit question: “find every pull-request comment written by this author across this repository.”

In a repository-wide review audit, the caller currently has to:

1. enumerate pull requests separately;
2. choose and hydrate each exact pull request;
3. inspect the resulting review facets;

[Read the thread](https://github.com/morluto/gitcontribute/issues/256) · 2026-08-01 · closed · 1 comment

### [Feature] Evaluate a contribution preflight for existing authored PRs

## Description

GitContribute can already resolve the authenticated identity, sync an authored PR portfolio, inspect a local workspace, and compare stored candidates with stored PRs. However, those operations do not provide a bounded preflight that can answer *before new work starts* whether a local candidate already corresponds to an open authored pull request.

This is a workflow gap, not a claim that an individual existing operation is incorrect.

## Reproduction

In a contribution workflow f

[Read the thread](https://github.com/morluto/gitcontribute/issues/252) · 2026-08-01 · closed · 0 comments

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