MCP calls reject valid developer key after successful setup

[FungousLand1941]

Summary

mantis setup succeeds with a fresh live developer key: it can list accessible Spaces, select an owned Space, create a new thread, and persist the active context. Immediately afterward, every MCP-backed command (mantis use get_space_context, mantis tools) fails with:

Streamable HTTP error: Error POSTing to endpoint: {"error":"Invalid or expired MCP bearer token"}
Assertion failed: !(handle->flags & UV_HANDLE_CLOSING), file src\win\async.c, line 76

This looks like an auth-contract mismatch between the REST endpoints used by setup and /mcp_integrated/ rather than a bad developer key, because the same key successfully authenticates REST operations during setup.

Environment

• Windows PowerShell
• Node v24.13.1
• mantisai-cli / mantis v3.7.0
• API base: https://kellis-h200-1.csail.mit.edu
• Owned Space selected successfully
• New thread created successfully

Reproduction

1. npm install -g mantisai-cli
2. mantis setup
3. Enter the default API base.
4. Enter a newly generated live_... developer key.
5. Browse Spaces, select an owned Space.
6. Create a new thread.
7. Setup reports success and mantis status shows the selected Space/thread.
8. Run mantis use get_space_context.
9. Observe Invalid or expired MCP bearer token.
10. Run mantis tools and observe the same auth error plus the libuv assertion on Windows.

Why this appears inconsistent with the documented/client contract

Current CLI/docs say the developer key is sent to <api-base>/mcp_integrated/ as Authorization: Bearer <key> with X-Space-State-ID. The same key is accepted by /api/v1/me/spaces/ and /api/v1/me/space-states/ during setup, but rejected by the MCP endpoint.

Expected

A valid developer key that succeeds during setup should also authenticate MCP calls, so mantis use get_space_context and mantis tools work immediately after setup.

Additional issue

The Windows process also hits:

Assertion failed: !(handle->flags & UV_HANDLE_CLOSING), file src\win\async.c, line 76

after the MCP HTTP auth failure. That looks like a cleanup/double-close issue in the failure path and may merit a separate guard/test.

No API keys or secrets are included in this report.