[BUG] v0.135.0 regression: MCP OAuth callback server fails to bind, all MCP servers stuck at "connecting..." in /mcp UI

[listell-writer]

Summary

After upgrading to droid 0.135.0, the /mcp panel shows every configured MCP server stuck at connecting... indefinitely and no MCP tools are registered. Downgrading to 0.104.0 (or 0.134.0) restores normal behaviour with the same ~/.factory/mcp.json and same machine. The root cause from logs is that the MCP OAuth callback HTTP server fails to bind at startup, which then aborts list_mcp_servers / list_mcp_tools in the background JSON-RPC worker.

Environment

• Droid version (broken): 0.135.0
• Droid version (last known good): 0.134.0 (also confirmed working: 0.104.0)
• OS: macOS 25.5.0, arm64
• Terminal: VS Code integrated terminal (1.121.0)
• Mode: interactive CLI, JSON-RPC sub-mode (isDroidExec=true, isStreamJsonRpcWorker=true)
• MCP config: ~/.factory/mcp.json, 10 servers (mix of stdio, HTTP, and SSE transports, several with OAuth)

Symptom

/mcp shows all 10 servers at connecting... indefinitely; no spinner progress, no error UI is ever surfaced. Ctrl+L (the workaround from #621) does not refresh the state.

Logs (~/.factory/logs/droid-log-single.log)

Same machine, same mcp.json, two consecutive sessions:

0.134.0 — success:

INFO: [metrics_log_mcp_callback_server_start_latency_ms]
  outcome: "success"
  value: 0.018 ms
  version: "0.134.0"

0.135.0 — fails immediately on every session start:

INFO: [metrics_log_mcp_callback_server_port_retry_count]
  outcome: "error"
  value: 1
  version: "0.135.0"

INFO: [metrics_log_mcp_callback_server_start_latency_ms]
  attempted: true
  outcome: "error"
  value: 6.82 ms
  version: "0.135.0"

WARN: [McpService] Error reloading MCP servers
  cause: MetaError: Failed to start MCP OAuth callback server
    at startOAuthCallbackServerIfNeeded (src/services/mcp/oauth/...)

ERROR: [JsonRpc] Background MCP startup failed during list_mcp_servers
MetaError: Failed to start MCP OAuth callback server
    at start (src/services/mcp/oauth/CallbackServer.ts:155:17)
    at processTicksAndRejections (native:7:39)
  cause: MetaError: Failed to start OAuth callback server
    at start (src/services/mcp/oauth/CallbackServer.ts:155:17)

ERROR: [JsonRpc] Background MCP startup failed during list_mcp_tools
  (same stack as above)

INFO: [SessionStateManager] MCP status changed
  count: 0
  totalCount: 0
  state: "no-servers"

The retry counter shows value: 1 with outcome: error, suggesting the port-pick loop gives up after a single failed attempt rather than scanning further free ports.

For comparison, the 0.104.0 startup on the same box succeeds and logs:

INFO: OAuth callback server started
  port: 54621

followed by [McpHub] Sending toolsChange notification with toolCount: 186 across all 10 servers.

Suspected cause

CallbackServer.ts:155 rejects on a single failed listen() rather than retrying with a different port, and the underlying listen error is swallowed by the wrapper (Failed to start OAuth callback server with no EADDRINUSE / EACCES detail in cause.cause). Likely a 0.134 → 0.135 change to the OAuth callback server startup path (port selection, bind options, or IPv6 binding on macOS). Surfacing the inner Error from net.Server would help diagnose; either way the bind retry budget appears to be effectively 1.

Reproduction

1. macOS, droid 0.135.0, any ~/.factory/mcp.json with one or more HTTP/SSE servers (OAuth-capable).
2. Launch droid, open /mcp.
3. All servers remain at connecting....
4. droid update --version 0.104.0 (or 0.134.0) → same config, all servers connect, tools register.

Impact

Complete loss of MCP functionality in 0.135.0 for users with any OAuth-capable MCP server configured. No degraded path, no error surfaced to the UI, only connecting....

Workaround

droid update --version 0.134.0 until a fix lands.

[listell-writer]

Additional data point: this also breaks concurrent sessions, and the regressed retry budget is the cause

The same defect has a second, very common trigger beyond the single-session case in the original report: running more than one droid CLI session on the same machine at once. Confirmed on 0.140.0.

Reproduction

1. Configure at least one OAuth/HTTP MCP server that uses a fixed callback port. In my case it's the Slack HTTP plugin, which pins its OAuth redirect to http://localhost:3118/ (see [FEAT] Support pre-registered OAuth clients for HTTP MCP servers (for Slack and others that reject Dynamic Client Registration) #996 for why that port is fixed and not negotiable).
2. Launch droid in terminal A. It binds the OAuth callback on 3118 and connects all servers normally.
3. Launch a second droid in terminal B (different repo, doesn't matter).
4. Terminal B: every MCP server sits at connecting... forever — stdio servers included, not just the OAuth ones.

Log evidence (droid-log-single.log, anonymised)

WARN: OAuth callback port is in use, retrying on next port
  { "port": 3118, "attempt": 1, "maxAttempts": 1,
    "error": "Failed to start server. Is port 3118 in use?" }

WARN: [McpService] Error reloading MCP servers
  cause: MetaError: Failed to start MCP OAuth callback server
    at startOAuthCallbackServerIfNeeded (src/services/mcp/McpService.ts:625:17)
    at runStartSequence (src/services/mcp/McpService.ts:644:18)

MetaError: Failed to start OAuth callback server
    at start (src/services/mcp/oauth/CallbackServer.ts:152:17)

The message says "retrying on next port" but maxAttempts: 1 means no retry actually happens — it gives up on the first EADDRINUSE and aborts the entire MCP reload, taking down stdio servers that never needed a callback at all.

Regression bound (ties this to a concrete prior behaviour)

Closed issue #289 shows the same bind path failing on a busy port, but with "attempt": 100 — i.e. the callback server used to scan up to 100 candidate ports before giving up. With that budget, a busy 3118 would simply be skipped and the second session would bind 3119/3120/etc. and work. The retry budget regressed from 100 → 1 somewhere between 0.22.x and 0.135.0, which is what turned a harmless "port busy, try the next one" into "all MCP dead." #205 (subagent OAuth callback port conflict) is the same class of failure from the subagent path.

Suggested fixes (any one resolves the concurrent-session case)

1. Restore the multi-attempt free-port scan in CallbackServer (the attempt: 100 behaviour from 0.134 and earlier). Cheapest fix, directly reverts the regression.
2. Make a callback-bind failure non-fatal: disable only the OAuth servers that need the callback and keep stdio + already-authenticated servers connected, instead of aborting the whole reload. Defensive regardless of (1).
3. Honour a configurable oauth.callbackPort per server (the ask in [FEAT] Support pre-registered OAuth clients for HTTP MCP servers (for Slack and others that reject Dynamic Client Registration) #996) so fixed-port servers like Slack can be assigned distinct ports and coexist across sessions.

Impact

As shipped, you cannot run more than one concurrent droid session if any OAuth/fixed-port MCP server is configured — the second session loses all MCP tooling, stdio included, with no error surfaced in /mcp (just connecting...). Still reproduces on the latest 0.140.0; no fix referenced against this issue yet.