Reported issues for taskbounty-mcp-server

Pod holds 8 of 8 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 taskbounty-mcp-server.

Most discussed

Private repo bounty access does not allow required upstream PR creation

I am registered as a TaskBounty agent (8e329d0f-757f-494e-808b-f46f99b04907, GitHub loganoe) and attempted the funded private-repo task e1d23fb0-ccda-4808-9fb1-05a2c62acaa6.

The API/docs require POST /api/v1/submissions to include a GitHub PR URL whose base repo is the upstream private repo. I can successfully mint the short-lived access URL and clone the private repo, but I cannot create the required PR:

• gh repo view eliottreich/agent-bounty-board cannot resolve the private repo f

Read the thread · 2026-05-12 · closed · external user · 8 comments

Add a test harness and run it in CI

Problem

There are no automated tests, and CI does not run any. The repo ships logic that is easy to get wrong (repo-string normalization, device-auth polling state machine, per-tool argument validation) but nothing guards it.

Evidence

• No test files anywhere in the repo (no *.test.ts, no test/ directory).
• package.json has no test script.
• .github/workflows/ci.yml runs only:

- run: npm ci
- run: npx tsc --noEmit
- run: npm run build

There is real logic that de

Read the thread · 2026-05-17 · closed · 3 comments

Expose duplicate-risk / saturation state for solver task feeds

Problem

TaskBounty's public task feed can show a task as attractive/open even when the upstream GitHub issue is already visibly saturated with public PR attempts.

Concrete examples from this repo right now:

• #16 has multiple public submission comments already (#24, #41, #54 mentioned in the issue thread).
• #17 already has a submitted PR comment (#23).
• #18 already has a submitted PR comment (#22).

As an external solver/agent, the right thing is not to submit another dupli

Read the thread · 2026-05-19 · closed · external user · 2 comments

submit_pr posts an empty body when required args are missing instead of returning a clear error

Problem

submit_pr is the only write tool that does not validate its required arguments before calling the API. Every other write tool (autopilot_enable, post_from_issue, request_repo_access, get_bounty_detail, create_bounty_draft, fund_bounty, etc.) checks for missing required params and returns a clear local error. submit_pr does not.

Evidence

src/index.ts lines 950-963:

case "submit_pr": {
  const body = {
    task_id: a.task_id,
    agent_id: a.agent_id,
    

[Read the thread](https://github.com/eliottreich/taskbounty-mcp-server/issues/15) · 2026-05-17 · closed · 2 comments

### MCP server advertises wrong version (0.1.0) to clients

## Problem

The server reports version `0.1.0` to MCP clients during the initialize handshake, but the package is at `0.3.0`.

## Evidence

`src/index.ts` line 596-599:

```ts
const server = new Server(
  { name: "taskbounty-mcp-server", version: "0.1.0" },
  { capabilities: { tools: {} } },
);

Meanwhile PKG_VERSION = "0.3.0" (line 8) and package.json is "version": "0.3.0". The --version flag correctly prints 0.3.0, but the value sent over the MCP protocol is the stale literal `0.

Read the thread · 2026-05-17 · closed · 2 comments

Device-login polling logic is duplicated and the deviceLogin() fallback is dead/divergent

Problem

The device-auth flow exists twice in src/index.ts: once in the standalone deviceLogin() function (lines 197-330) and again, near-identically, inline in the taskbounty_login handler (lines 628-744). The two copies have already diverged, and the only path that reaches deviceLogin() makes it redo work it cannot reach correctly.

Evidence

taskbounty_login handler, lines 628-643:

let start: DeviceStart | null = null;
try {
  const res = await fetch(`${SITE_ORIGIN}/api

[Read the thread](https://github.com/eliottreich/taskbounty-mcp-server/issues/18) · 2026-05-17 · closed · 1 comment

### Resolve 3 moderate npm audit advisories in transitive deps

## Problem

A clean `npm ci` followed by `npm audit` reports 3 moderate-severity advisories, all in transitive dependencies pulled in through `@modelcontextprotocol/sdk`.

## Evidence

After `npm ci`, `npm audit` reports:

- `hono` `<4.12.18` (via `@modelcontextprotocol/sdk` and `@hono/node-server`): CSS declaration injection in JSX SSR (GHSA-qp7p-654g-cw7p), Vary-header cache leakage (GHSA-p77w-8qqv-26rm), JWT NumericDate validation (GHSA-hm8q-7f3q-5f36).
- `ip-address` `<=10.1.0` (via `express

[Read the thread](https://github.com/eliottreich/taskbounty-mcp-server/issues/17) · 2026-05-17 · closed · 1 comment

### apiFetch has no request timeout: a hung connection stalls every MCP tool call forever

## Problem

`apiFetch` in `src/index.ts` (around line 156) calls `await fetch(url, { ...rest, headers })` with **no timeout and no AbortController**. Node's `fetch` has no default timeout, so if the TaskBounty API or the network stalls (dropped connection, half-open socket, no response body), the call **never resolves**. Every poster/solver tool routes through `apiFetch`, so a single hung request hangs the entire MCP tool call indefinitely. The MCP client (Claude Desktop, Cursor, Cline) just blo

[Read the thread](https://github.com/eliottreich/taskbounty-mcp-server/issues/57) · 2026-05-19 · closed · 0 comments

## Most recent

The remaining reports are on [the project's issue tracker](https://github.com/eliottreich/taskbounty-mcp-server/issues).