Amazon Quick Desktop’s enterprise SSO login (OIDC-based, per the enterprise deployment setup guide
( Setting up Amazon Quick on desktop for enterprise deployments - Amazon Quick )) fails silently/hangs when local port
127.0.0.1:18080 is already bound by another application. Quick Desktop appears to use a hardcoded fixed port (18080) for its
local OAuth/OIDC loopback redirect listener rather than an OS-assigned ephemeral port, which is the standard, more robust
pattern for native-app OAuth loopback flows (see RFC 8252, Section 7.3, which specifically recommends ephemeral ports to
avoid exactly this class of conflict).
Confirmed root cause, from Quick Desktop’s own log output:
ERROR [aws_quick_work.qw_hypervisor.server.ws_gateway] Login failed for provider enterprise: Port 18080 in use: [Errno 48]
error while attempting to bind on address (‘127.0.0.1’, 18080): [errno 48] address already in use
Steps to reproduce:
1. Start any other local application that binds 127.0.0.1:18080 first. In my case, this was a background helper process (Kiro
Helper (Plugin)) belonging to the Kiro IDE/CLI application, which binds that port on every launch — I’ve filed the
corresponding issue on that side too: Kiro Helper process hardcodes bind to 127.0.0.1:18080, conflicts with other local apps' OAuth loopback callbacks (observed conflict with Amazon Quick Desktop) · Issue #10031 · kirodotdev/Kiro · GitHub
2. Launch Amazon Quick Desktop and select “Continue with SSO” for enterprise sign-in.
3. Complete login in the browser (this step succeeds — the browser-side OIDC redirect to the IdP and back works fine).
4. Quick Desktop’s local callback listener fails to bind, the desktop app never receives the callback, and login hangs/fails
with the diagnostic output {“error”: “Agent not reachable: fetch failed”} or similar, depending on version.
5. Quick Desktop’s own logs show the EADDRINUSE error on port 18080 shown above.
Workaround currently in use: Fully quit the conflicting application (in my case, Kiro) before starting the Quick Desktop SSO
login, then relaunch it afterward. This is not durable — the conflict recurs any time Quick Desktop needs to re-authenticate
while the other application is running, since both apps want the same port and only one can hold it at a time.
Expected Behavior:
Quick Desktop’s enterprise SSO loopback listener should bind to a dynamically-assigned (OS-chosen) ephemeral port at each
login attempt, rather than a fixed port (18080), so it cannot collide with other local applications that may already be using
that port. At minimum, if binding to 18080 fails, Quick Desktop should retry on an alternate port automatically and complete
the login, rather than failing the flow entirely with no user-facing recovery path.
Note: This is not exclusively a Quick Desktop bug — it’s a two-sided port conflict. I’ve also filed the corresponding report
against the other application involved (Kiro: Kiro Helper process hardcodes bind to 127.0.0.1:18080, conflicts with other local apps' OAuth loopback callbacks (observed conflict with Amazon Quick Desktop) · Issue #10031 · kirodotdev/Kiro · GitHub
( Kiro Helper process hardcodes bind to 127.0.0.1:18080, conflicts with other local apps' OAuth loopback callbacks (observed conflict with Amazon Quick Desktop) · Issue #10031 · kirodotdev/Kiro · GitHub )), since its helper process claims port 18080 unconditionally on every
launch. However, I believe Quick Desktop’s use of a hardcoded, well-known port for an OAuth loopback callback (rather than an
ephemeral one, which is the recommended pattern for this exact scenario) is the more fundamental design gap, since it’s the
side that’s inherently vulnerable to collision with any other locally-running process that happens to use that port.