Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/kaneo/issues.md or /mcp/kaneo/issues.json, or Pod over MCP.

Reported issues for kaneo

Pod holds 7 of 7 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 kaneo.

Most discussed

MCP tools return 'fetch failed' on localhost self-hosting: server-side calls use the public KANEO_API_URL

Summary

On a self-hosted install reached over localhost, every built-in MCP tool returns:

{ "error": "fetch failed" }

OAuth completes fine and the server shows as connected — whoami, list_workspaces, list_projects all fail the same way. The cause is that the MCP handler performs server-side fetches against the public URL, which does not resolve from inside the container.

Root cause

apps/api/src/mcp/index.ts derives its API base from the public env var:

`

Read the thread · 2026-08-09 · closed · external user · 1 comment

[Bug]: Remote MCP OAuth returns invalid_client when requests hit different Kaneo replicas

Bug Description

The built-in remote MCP OAuth flow fails when Kaneo runs with multiple replicas.

Dynamically registered OAuth clients, pending authorization requests and authorization codes are stored in process-local Map instances.

If /api/mcp/register reaches replica A and /api/mcp/authorize reaches replica B, replica B cannot find the registered client and returns:

{"error":"invalid_client"}

The issue was reproduced deterministically with Kaneo v2.12.1. Sending both

Read the thread · 2026-08-04 · closed · external user · 20 comments

Publish @kaneo/mcp to npm — task-relation tools missing since #1341

Summary

@kaneo/mcp on npm is stuck at 0.1.5 (2026-04-06) and does not include the task-relation / delete_label MCP tools that landed on main in #1341 (merged 2026-06-25).

Self-hosted consumers who follow the docs (npx -y @kaneo/mcp serve) therefore get an incomplete tool surface vs the UI and vs the in-API MCP registry.

What’s missing on npm 0.1.5

Read the thread · 2026-07-21 · closed · external user · 2 comments

[Bug]: Comments created via MCP are not visible in the UI and vice versa — two parallel comment systems are out of sync

Bug Description

The codebase has two completely separate comment systems that operate on different database tables and API routes, causing comments to be invisible across surfaces:

  1. UI (Web) — stores comments in activityTable (table: activity) as rows with type: "comment". Uses /api/activity/comment endpoints. Fetcher files (comment) call client.activity.comment.$post/$put/$delete.
  2. MCP + /api/comment route — stores comments in a separate commentTable (table: comment). Uses /api/commen

Read the thread · 2026-07-06 · closed · outside contributor · 1 comment

feat: MCP Auth with API Token

Problem Statement

I can't use the mcp auth process to authenticate as my agents are running inside a sandboxed docker environment and don't always show the url, and when they do it times out before I get to process this in the browser.

Proposed Solution

Is there no way to use the API keys I can create in the interface?

Alternative Solutions

Some kind of hands free auth flow that doesn't require human interaction.

Does this feature align with Kaneo's focus on simplicity?

It would

Read the thread · 2026-05-01 · closed · external user · 1 comment

feat: Add remote MCP server

Problem Statement

Kaneo already ships an official MCP server (@kaneo/mcp in packages/mcp/), which is a great foundation. However, the current implementation uses stdio transport, meaning every user must:

  1. Have Node.js 20+ installed
  2. Run npx @kaneo/mcp or install the package globally
  3. Understand how to configure MCP clients

This creates a significant barrier to entry. Non-technical users, team leads tracking project status through AI tools, or teams without Node.js in th

Read the thread · 2026-04-07 · closed · outside contributor · 4 comments

feat: OIDC-only User Registration

Problem Statement

It would be nice to allow OIDC user registrations even when DISABLE_REGISTRATION=true.

Proposed Solution

A new env to DISABLE_PASSWORD_REGISTRATION leaving the global DISABLE_REGISTRATION behavior alone.

Does this feature align with Kaneo's focus on simplicity?

Yes, it would allow the IDP to determine a user's access to kaneo without additional invite steps.

Read the thread · 2026-03-14 · closed · external user · 1 comment

Most recent

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