# 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](/mcp/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](https://github.com/eliottreich/taskbounty-mcp-server/issues/4) · 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:

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

There is real logic that de

[Read the thread](https://github.com/eliottreich/taskbounty-mcp-server/issues/16) · 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](https://github.com/eliottreich/taskbounty-mcp-server/issues/61) · 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:

```ts
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](https://github.com/eliottreich/taskbounty-mcp-server/issues/14) · 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:

```ts
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).