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.

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 · 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), while MCP serving does ([internal/cli/cli.go](https://github.com/morluto/gitcontribute/blob/9c96943dd07fb32efc2b8a7ea8791444e3f2ddc2/internal/cli/cli.go#L514-L51

Read the thread · 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 · 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 · 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 · 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:

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

The call returned:

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 · 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 · 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 · 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:

{
  "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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 2026-08-01 · closed · 0 comments

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