Repository navigation
[FEATURE]: MCP OAuth: let the engine choose and hold its loopback listener per attempt and report it #57130
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Related, not the same: #31014 (closed as not planned) asked to configure the provider-facing redirect URI separately from the local listener address. This request asks for something different: that the engine owns its loopback listener for each attempt and reports it, so an integration never has to pick and release a port for the engine.
Describe the enhancement you want to request
MCP OAuth behind an existing authenticated front server
A front server can provide the public OAuth callback while the engine owns the private OAuth attempt. Today it must configure a local callback port before Start and release any reservation before the engine binds it. This creates a bind race and requires extra coordination outside the engine.
Could a per-attempt API let the engine choose and hold its private listener, independently of the external redirect address, then return the resolved loopback address with the attempt identity through the authenticated API? Start must not return the authorization URL until the listener and attempt are owned. Cancellation, expiry and failed setup must close it, and status/recovery must identify an attempt whose Start reply was lost. The front server must retain its own record selection and callback checks.
A supported external-callback continuation that accepts a claimed response for an opaque attempt, with no second listener, would remove more coordination. A held-listener adoption API is another possible contract when an integration can transfer a real socket. Neither route should require temporary persistent configuration edits or an arbitrary remote destination supplied by a browser.
Activity
opencode-agent commentedon Oct 19, 2026
Thanks for the detailed request! In short, you'd like MCP OAuth to have a per-attempt API. The engine would bind and hold its own loopback callback listener, then return the resolved address and an attempt ID before giving out the authorization URL. It would clean the listener up on cancel, expiry or failure, and let you recover an attempt whose Start reply was lost. That way a front server that proxies the public callback never has to reserve a port and release it for the engine. You also suggest an external-callback continuation as an alternative.
Right now, v2 binds the listener on
127.0.0.1usingoauth.callback_port. If that isn't set, it uses the port fromredirect_uri, or an ephemeral port as a last resort. It doesn't report the chosen port or the attempt back to the caller, so this would need a new core API. It can't be done as a plugin.Related issues:
The maintainers will consider it.