Mood: 😔
Category: Bugs
Title: Desktop app shows permanent "authenticating" status for third-party OAuth MCP servers (connection actually works)
Environment:
Desktop app: 1.0.12 (macOS)
Bundled CLI SDK / daemon: 1.0.66-1
OS: macOS
Summary:
An MCP server that authenticates via a third-party (non–first-party-GitHub) OAuth provider shows a permanent "authenticating" status in the UI. The server is actually connected and fully functional — its tools respond normally — but the status badge never resolves to connected.
Steps to reproduce:
Configure an MCP server whose OAuth protected resource is not the first-party GitHub token endpoint.
Launch the app and let the server connect.
Observe the server's status in the UI.
Expected behavior:
The UI status reflects the actual connection state. A server whose tools are working should show as connected.
Actual behavior:
The status badge stays on "authenticating" indefinitely, with no auth flow (e.g. browser window) ever opening, even though the server is connected and tools return data.
Evidence from logs:
The UI status subscription and the tool/session connection are independent. In subscribe_mcp_status:
First-party servers log:
MCP OAuth answered with first-party GitHub token → MCP OAuth-pinned status session connected (badge resolves immediately).
The third-party server logs:
MCP OAuth host-token broadcast; awaiting host response — and never proceeds. The host never answers, so the status subscription never resolves.
Evidence from the app binary:
The desktop app binary (Contents/MacOS/github) contains:
auth/required for unrecognized protected resource; daemon will keep requesting auth until a client update adds support
auth/required notification; marking host as needing re-auth
authenticate_host: AuthRequired from daemon
This indicates the daemon correctly raises auth/required for the protected resource, but the app's host-auth handler only satisfies the first-party GitHub token path and has no handler for unrecognized/third-party protected resources — so it never answers, and the daemon keeps requesting auth.
Root cause (suspected):
The bug is in the desktop app's host-auth handling (the app is the daemon's "client" referenced in the log message), not in the daemon. Support for satisfying auth for generic/third-party OAuth protected resources in the status/host path appears to be missing.
Impact:
Cosmetic but misleading — the server works, but the UI implies auth is pending/failed, and there is no way to clear or resolve the badge.
Notes:
Confirmed on the latest available app version, which pins the latest bundled daemon; no newer version resolves it.
The tool/session connection works correctly (verified: tools return data while the badge still shows "authenticating").
| Field |
Value |
| App version |
1.0.12 |
| OS |
macOS 26.5.1 |
| Theme |
GitHub |
| Path |
/chat |
| Tenure |
Week 2 |
Mood: 😔
Category: Bugs
Title: Desktop app shows permanent "authenticating" status for third-party OAuth MCP servers (connection actually works)
Environment:
Desktop app: 1.0.12 (macOS)
Bundled CLI SDK / daemon: 1.0.66-1
OS: macOS
Summary:
An MCP server that authenticates via a third-party (non–first-party-GitHub) OAuth provider shows a permanent "authenticating" status in the UI. The server is actually connected and fully functional — its tools respond normally — but the status badge never resolves to connected.
Steps to reproduce:
Configure an MCP server whose OAuth protected resource is not the first-party GitHub token endpoint.
Launch the app and let the server connect.
Observe the server's status in the UI.
Expected behavior:
The UI status reflects the actual connection state. A server whose tools are working should show as connected.
Actual behavior:
The status badge stays on "authenticating" indefinitely, with no auth flow (e.g. browser window) ever opening, even though the server is connected and tools return data.
Evidence from logs:
The UI status subscription and the tool/session connection are independent. In subscribe_mcp_status:
First-party servers log:
MCP OAuth answered with first-party GitHub token → MCP OAuth-pinned status session connected (badge resolves immediately).
The third-party server logs:
MCP OAuth host-token broadcast; awaiting host response — and never proceeds. The host never answers, so the status subscription never resolves.
Evidence from the app binary:
The desktop app binary (Contents/MacOS/github) contains:
auth/required for unrecognized protected resource; daemon will keep requesting auth until a client update adds support
auth/required notification; marking host as needing re-auth
authenticate_host: AuthRequired from daemon
This indicates the daemon correctly raises auth/required for the protected resource, but the app's host-auth handler only satisfies the first-party GitHub token path and has no handler for unrecognized/third-party protected resources — so it never answers, and the daemon keeps requesting auth.
Root cause (suspected):
The bug is in the desktop app's host-auth handling (the app is the daemon's "client" referenced in the log message), not in the daemon. Support for satisfying auth for generic/third-party OAuth protected resources in the status/host path appears to be missing.
Impact:
Cosmetic but misleading — the server works, but the UI implies auth is pending/failed, and there is no way to clear or resolve the badge.
Notes:
Confirmed on the latest available app version, which pins the latest bundled daemon; no newer version resolves it.
The tool/session connection works correctly (verified: tools return data while the badge still shows "authenticating").