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/no-human/issues.md or /mcp/no-human/issues.json, or Pod over MCP.

Reported issues for no_human

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

Most discussed

Port the MCP bridge to the SDK's 2.x API so the mcp<2 cap can be lifted

Follow-up to #15. src/no_human/intake/mcp_bridge.py imports mcp.server.fastmcp, which the MCP Python SDK removed in 2.0.0, so pyproject.toml now caps the dependency at mcp>=1.28.0,<2. That cap is correct for a hotfix, but it shouldn't become permanent by neglect — new SDK work happens on 2.x.

What the 2.x replacement looks like (verified against mcp==2.0.0 during the review of the cap):

Read the thread · 2026-08-20 · open · outside contributor · 0 comments

nh mcp-serve fails with ModuleNotFoundError on any PyPI install (mcp 2.0.0 dropped mcp.server.fastmcp)

Affects 0.1.1, 0.1.2 and 0.1.3 — anyone who installed from PyPI.

$ uvx no-human mcp-serve
ModuleNotFoundError: No module named 'mcp.server.fastmcp'

Same failure for nh mcp-serve after uv tool install no-human, and for the Claude Code plugin (plugins/no-human/.mcp.json runs nh mcp-serve).

Cause. src/no_human/intake/mcp_bridge.py imports mcp.server.fastmcp. The MCP Python SDK removed that path in 2.0.0, and our requirement was mcp>=1.28.0 with no upper bound —

Read the thread · 2026-08-20 · closed · outside contributor · 2 comments

docs/security.md references a non-existent nh integrations command

`docs/security.md` (the "Integration health checks" bullet, around line 218) says "`nh integrations` / the board's integrations page authenticate against…".

``` $ nh integrations --help Error: No such command 'integrations'. ```

The board surface exists (`/api/integrations` and `/api/integrations/{name}/test` in `src/no_human/api/app.py`); only the CLI verb is fictional. The bullet's inline citations into `src/no_human/integrations/init.py` have also drifted — the statu

Read the thread · 2026-08-20 · open · outside contributor · 0 comments

MCP bridge hard-codes 127.0.0.1:8420 instead of honouring server.port

`src/no_human/intake/mcp_bridge.py` line 29 fixes the API base URL:

```python BASE_URL = "http://127.0.0.1:8420" ```

That constant is the only thing `_client()` and `_ensure_api_reachable()` use; the module never reads config. The server side does: `nh start` binds `server.port` from `~/.no_human/config.yaml` (`DEFAULT_CONFIG['server'] == {'host': '127.0.0.1', 'port': 8420}`, documented in `docs/configuration.md`). So an operator who moves the board to another port gets:

Read the thread · 2026-08-20 · open · outside contributor · 0 comments

docs: COST_LEVERS.md still says "a single Claude backend"

docs/COST_LEVERS.md line 55 reads:

the product keeps a single Claude backend via the Agent SDK and never re-implements capabilities the SDK already owns

The first half is out of date: the coder can also run on OpenAI Codex (worker.backend: codex; see docs/BACKENDS.md). The second half — never re-implement what the SDK owns — still holds and is the point the sentence is making.

What to do: reword that parenthetical so it makes its actual argum

Read the thread · 2026-08-19 · closed · outside contributor · 2 comments

docs: configuration.md does not document worker.backend (claude | codex)

worker.backend chooses which coding backend the implementer runs on — claude (default, the Claude Agent SDK) or codex (the OpenAI Codex CLI, on your own OPENAI_API_KEY). It is implemented (src/no_human/agent/backend.py resolve_backend_name/make_backend, src/no_human/agent/codex_backend.py) and covered in docs/BACKENDS.md, but docs/configuration.md — which the README calls "every setting and default" — never mentions it.

grep -c 'w

[Read the thread](https://github.com/no-human-ai/no_human/issues/1) · 2026-08-19 · closed · outside contributor · 1 comment

## Most recent

The remaining reports are on [the project's issue tracker](https://github.com/no-human-ai/no_human/issues).