[bug] Legacy DCR client can still be reused with a mismatched callback URI on v1.6.7 #1924

Executor version

1.6.7

How do you run Executor?

Desktop app

Operating system

macOS (Apple Silicon)

Integration involved

Remote MCP server using OAuth 2.1 and Dynamic Client Registration: https://mcp.modem.dev/mcp

What happened

While using Add connection with no active connection present, Executor reused a cached dynamically registered OAuth client whose registered callback was:

http://127.0.0.1:4789/api/oauth/callback

The new authorization flow instead sent:

http://localhost:4789/api/oauth/callback

The authorization server rejected the exact-string mismatch, leaving the integration with no connection and 0 tools.

We verified the mismatch independently:

• The cached client plus the localhost callback was rejected as an invalid redirect.
• The same client plus the registered 127.0.0.1 callback proceeded to the login page.
• The MCP server and OAuth discovery endpoints were otherwise healthy.

Deleting only the cached OAuth client was sufficient to recover; the integration itself did not need to be deleted. After Executor dynamically registered a replacement client with the current localhost callback, authorization completed and Executor discovered all 14 MCP tools.

This appears related to #1443 and #1542/#1559, but it occurred on v1.6.7 through Add connection, not Reconnect.

Possible cause (inference): the cached client may have been a legacy row with a null or missing origin_redirect_uri. It was deleted before that local metadata could be inspected. #1443 treats legacy rows without this metadata as matching, which may allow an older client to be reused after the callback origin changes.

What you expected

Before reusing a dynamically registered client, Executor should ensure it was registered for the exact callback URI used by the current flow.

If the registered callback cannot be determined, Executor should conservatively register a new client instead of reusing the cached one.

Steps to reproduce

1. Have a cached DCR OAuth client registered while Executor uses http://127.0.0.1:4789/api/oauth/callback.
2. Run Executor so the current callback is http://localhost:4789/api/oauth/callback.
3. Open the remote MCP integration with no active connection and select Add connection.
4. Observe that Executor reuses the cached client while sending the new localhost callback.
5. Observe the authorization server reject the request because the callback is not registered for that client.
6. Delete only the cached OAuth client and try Add connection again.
7. Observe a fresh dynamic registration and successful authorization.

Diagnostics / logs

No diagnostics archive attached. The failure was isolated with direct, credential-free authorization checks against both callback spellings. No client secrets, authorization codes, access tokens, refresh tokens, or PKCE verifier values are included in this report.

Before you submit

• I searched the open issues for a duplicate.
• I removed all keys, tokens, and credentials from this report.