Bug: GET api/servers Fails Within Headless Docker Container

[brandonja991]

Summary

In any environment without a working OS/D-Bus secret-service (e.g. a headless Docker container — no gnome-keyring, no org.freedesktop.secrets), adding any server — even a plain Streamable HTTP server with no OAuth config — causes every subsequent GET /api/servers to fail with:

Failed to read server list: Couldn't access platform storage: PermissionDenied

Environment

• @modelcontextprotocol/inspector@2.0.0
• Reproduced in Docker, run with DANGEROUSLY_OMIT_AUTH=true, DANGEROUSLY_BIND_ALL_INTERFACES=true — no D-Bus/secret-service daemon present, as is typical for minimal/CI containers.

Steps to Reproduce

1. Build a minimal container

Create a Dockerfile:

FROM node:24-alpine

RUN npm install -g @modelcontextprotocol/inspector@2.0.0

ENV HOST=0.0.0.0 \
    DANGEROUSLY_BIND_ALL_INTERFACES=true \
    DANGEROUSLY_OMIT_AUTH=true \
    MCP_AUTO_OPEN_ENABLED=false \
    CLIENT_PORT=6274

EXPOSE 6274

CMD ["mcp-inspector", "--web"]

Build and run it:

docker build -t inspector-repro .
docker run --rm -d -p 6274:6274 --name inspector-repro inspector-repro

Confirm it's up by opening http://localhost:6274 in your browser (HTTP, not HTTPS) — you should see the Inspector UI with an empty server list.

2. Add any server via the UI

1. Click Add Server → Add Manually.
2. Give it any name, e.g. test-server.
3. Set transport to Streamable HTTP.
4. Set the URL to any value, e.g. https://example.com/mcp.
5. Save/submit the server.

Expected: the server list loads normally and shows test-server.

Actual: the server list fails to load. The underlying GET /api/servers request (visible in browser dev tools) returns:

HTTP/1.1 500 Internal Server Error

{"error":"Failed to read server list: Couldn't access platform storage: PermissionDenied\n\nCaused by:\n    PermissionDenied"}

Root Cause

• expectedSecretFields() unconditionally includes the OAuth-client-secret field for every server, even ones with no OAuth config at all. This means rehydrateConfig() → readKeychainEntriesFor() → secretStore.get() runs a keychain lookup for every server on every GET /api/servers, regardless of whether that server could possibly have a stored secret.
• In KeyringSecretStore.get(), new AsyncEntry(SERVICE_NAME, buildAccount(serverId, field)) is constructed outside the surrounding try/catch — only the subsequent await entry.getPassword() is guarded.
• When there's no secret-service backend available, @napi-rs/keyring's AsyncEntry constructor throws synchronously, so it bypasses the KeychainUnavailableError-specific graceful-degradation path that already exists elsewhere in the codebase (e.g. in migratePlaintextSecrets()), and instead surfaces as a raw, unclassified error → generic 500 in the /api/servers route handler.

[koriyoshi2041]

I reproduced the synchronous-constructor escape described here and prepared a focused fix with regression coverage:

koriyoshi2041/inspector@main...koriyoshi2041:inspector:fix/keyring-constructor-failure

The change moves AsyncEntry construction inside each operation's existing availability boundary, preserving the documented contract (get returns null, delete no-ops, and set throws KeychainUnavailableError). It adds constructor-failure tests for all three operations. npm run validate:web passes: 258 test files / 3710 tests.

GitHub currently rejects PR creation from this account with createPullRequest permission / REST 404, so I am leaving the tested branch here rather than duplicating the report. If cross-fork PR creation is enabled or a maintainer wants the patch rebased elsewhere, I can follow up.

[Mahmoud-Eltohamy]

I have an infrastructure-level fix for this — making the Docker image ship with the
system packages @napi-rs/keyring actually requires.

Branch: https://github.com/MahmoudEltohamy/inspector/tree/fix/docker-keyring-deps

Changes to Dockerfile (runtime stage only):

1. Added libsecret-1-0, dbus, dbus-x11, gnome-keyring, gosu (~15 MB)
2. Added runtime directory setup for D-Bus + keyring
3. Replaced ENTRYPOINT ["mcp-inspector"] with an inline entrypoint script that:
   • Starts dbus-daemon --system (needed by gnome-keyring)
   • Drops to node user via gosu
   • Launches dbus-launch for a session bus
   • Unlocks gnome-keyring-daemon with an empty password
   • Execs mcp-inspector

This gives full keyring functionality in the container (secrets actually persist)
rather than silent degradation.

Happy to submit as a PR to v2/main if a maintainer can allow fork PRs, or feel
free to cherry-pick the Dockerfile changes directly.

[cliffhall]

Closing as a duplicate of #1848, which is now the single tracking issue for this bug.

Thanks for the report — it was not wasted. Three people hit this independently in different environments, which is a large part of the evidence that it affects essentially any containerized or keyring-less deployment rather than one unusual setup:

• web-ui in firefox fails to get servers: 500 error: Failed to read server list: Couldn't access platform storage: PermissionDenied #1845 — web UI, PermissionDenied on GET /api/servers
• Bug: GET api/servers Fails Within Headless Docker Container #1918 — headless Docker, no gnome-keyring / org.freedesktop.secrets
• GET /api/servers fails in container with Couldn't access platform storage: PermissionDenied #1931 — Docker Swarm container behind Traefik, ghcr.io/…/inspector:2.1.0
• KeyringSecretStore throws from the AsyncEntry constructor, defeating its own degradation contract (500 on GET /api/servers) #1848 — the diagnosed root cause, where the fix is tracked

Root cause: @napi-rs/keyring's AsyncEntry constructor does the platform-store setup and throws when no secret service is reachable. It is constructed outside the try in get/set/delete in core/auth/node/secret-store.ts, so the graceful-degradation path that already exists never engages — the raw error escapes and 500s every GET /api/servers.

Your analysis carried a second finding beyond the constructor bug — that expectedSecretFields() runs a keychain lookup for every server even with no OAuth config at all. I have quoted it in full on #1848 so it survives this issue closing; it explains why the failure fires so broadly.

Subscribe to #1848 for the fix. No further action needed here.