Gong plugin: desktop OAuth can't be completed — Gong rejects the http://localhost:8787/callback redirect URI

Bắt đầu với bước 2 của third_party/gong/README.md và lần theo cấu hình callback OAuth trên desktop được plugin Gong sử dụng. Xác nhận callback đã chọn hoạt động với việc xác thực redirect-URI của Gong, cập nhật thiết lập được ghi lại và kiểm tra để bảo đảm việc cấp quyền trên desktop hoàn tất mà không có unauthorized_client.

Summary

The Gong plugin's documented setup can't be completed on desktop. third_party/gong/README.md step 2 tells admins to register http://localhost:8787/callback as a redirect URI on the Gong MCP integration, but Gong's admin API refuses to store any http:// redirect URI. Since that URI can never be whitelisted, desktop OAuth always ends in unauthorized_client.

Error

After clicking ALLOW on Gong's consent screen, the browser lands on:

http://localhost:8787/callback?error=unauthorized_client&error_description=This%20MCP%20client%20is%20not%20authorized%20for%20your%20company.%20Please%20ask%20your%20Gong%20technical%20admin%20to%20authorize%20it.

The message points at the admin, which sends people hunting for an approval setting that doesn't exist. The real cause is the redirect URI.

Why the documented step can't be done

Gong's Redirect URL field accepts https:// only:

• Saving http://localhost:8787/callback → the admin API PUT returns 400 Bad Request; on a retry the line is silently dropped from the saved list.
• The same field saves https:// URIs without complaint — including https://localhost:<port>/oauth/callback and the Cursor web callback already in the README.

So the scheme is what's rejected, not loopback itself.

Isolation

Same Gong integration, same client ID and secret, changing one variable at a time:

Scopes and the resource parameter make no difference. Only the redirect URI does.

One detail that makes this painful to diagnose: Gong renders the consent screen before validating the redirect URI. The flow looks healthy — the app name, the requested scopes, everything — right up until you click ALLOW. Only then does it reject. It's easy to conclude the callback is fine and go looking elsewhere.

Tested against both a Personal access and a Shared access integration, both Manual registration. Same result.

Suggested fixes

1. Use an https loopback callback for desktop, or route desktop through the same https://www.cursor.com/agents/mcp/oauth/callback that Web and Cloud Agents already use.
2. At minimum, update third_party/gong/README.md so admins aren't asked to register a URI that Gong won't accept.

RFC 8252 §7.3 expects native apps to use loopback redirects, so this is arguably worth raising with Gong as well — but as things stand their admin API rejects http://, so the plugin can't depend on it.

Environment

• Gong MCP server: https://mcp.gong.io/mcp
• Integration: Manual registration (client ID + secret)
• Plugin: third_party/gong 1.0.0