Sign-in fails with 404: appstoreconnect.apple.com/olympus/v1/app/config no longer exists

[Tai-Kimura]

Describe the bug

xcodes install fails immediately after the Apple ID prompt (before the password prompt) with:

Apple ID: <redacted>
The operation couldn't be completed. (NetworkError.non200StatusCode(statusCode: 404, data: Optional(423 bytes)))

The failing request is the unauthenticated service-key fetch:

GET https://appstoreconnect.apple.com/olympus/v1/app/config?hostname=itunesconnect.apple.com
→ 404, body = 423 bytes (Jetty/Jersey HTML error page)

The 423 bytes in the error matches this response byte-for-byte.

XcodesOrg/XcodesApp#850 reports the identical response for the GUI app. Filing here because the CLI is affected too and had no issue yet. The string olympus/v1/app/config is present in both the xcodes binary and Xcodes.app, so the two share this code path.

To Reproduce

xcodes install "27.0 Release Candidate"
# enter Apple ID → fails before the password prompt

Or without any credentials:

curl -s -o /dev/null -w '%{http_code}:%{size_download}\n' \
  'https://appstoreconnect.apple.com/olympus/v1/app/config?hostname=itunesconnect.apple.com'
# 404:423

Additional measurements

The 404 is specific to this one route, and everything around it is healthy:

Request	Result
GET /olympus/v1/app/config?hostname=itunesconnect.apple.com	404, 423 bytes
GET /olympus/v1/app/config (no query)	404, 423 bytes
GET /olympus/v1/session	401, 60 bytes (Unauthenticated)
POST idmsa.apple.com/appleauth/auth/federate	200
POST idmsa.apple.com/appleauth/auth/signin/init	302
POST idmsa.apple.com/appleauth/auth	403
POST developerservices2.apple.com/services/download	400

So olympus/v1 as a service is still up (/v1/session answers), and no other endpoint referenced by the binary returns 404/423. Only the app/config route is gone.

One negative control worth recording, because it is an easy wrong turn: GET /olympus/v2/app/config?hostname=itunesconnect.apple.com returns 401 Unauthenticated, which looks like "Apple moved it to v2". It is not. These all return the same 401/60 bytes:

/olympus/v2/app/config?hostname=itunesconnect.apple.com   401:60
/olympus/v2/zzz-not-a-real-path                           401:60
/olympus/v2/session                                       401:60
/olympus/v9/app/config                                    401:60

The 401 is a blanket gate applied to every non-v1 path, so it is not evidence that a v2 config endpoint exists.

Apple's system status pages showed no active incident while testing: the Developer status feed had 0 in-progress events (only two resolved ones dated 09/10), and the main Apple status feed had 0 events across all 78 services. Still reproducing as of 2026-09-11T01:13:58Z.

Note that xcodes list still works, since the version list comes from the Xcode Releases data source and does not touch Apple auth. Installing from an already-downloaded archive with xcodes install <version> --path <file.xip> also works, as it bypasses sign-in entirely — useful as a workaround in the meantime.

I have not been able to determine whether Apple removed this endpoint permanently or whether it is a temporary misconfiguration.

Version

• xcodes 2.0.3 (Homebrew, homebrew-core bottle arm64_tahoe)
• macOS Darwin 25.6.0, Apple Silicon

[winddpan]

same issue

[MSchmidt]

Workaround for now is to go to https://developer.apple.com/download/all/?q=Xcode to download the xcode xip file. Then install with:

# Xcode 27 RC
xcodes install 27 --path ~/Downloads/Xcode_27_Release_Candidate.xip

# Xcode 26.6
xcodes install 26.6 --path ~/Downloads/Xcode_26.6_Apple_silicon.xip

[Tai-Kimura]

Still reproducing as of 2026-09-11T08:23:39Z, roughly 7 hours after this was filed, so it doesn't look like a short blip:

GET /olympus/v1/app/config?hostname=itunesconnect.apple.com   404
GET /olympus/v1/session                                       401

/olympus/v1/session continues to answer, so only the app/config route is missing.

@MSchmidt's workaround is the right one in the meantime — and https://developer.apple.com/download/all/?q=Xcode is an easier place to find the .xip than the page I linked.

One correction to my original post: the response body is 422–423 bytes, not a fixed 423. The length tracks the servlet instance id embedded in the HTML (ServletContainer-2d801d8 at 7 hex chars vs ServletContainer-429e7914 at 8), so the byte count isn't a stable fingerprint — the URL, status, and page content are what identify it.

[iBotPeaches]

Yeah we are considering in fastlane that the endpoint is gone for good as the value we need (widgetKey) is delivered to page now vs endpoint. We found the signout endpoint ships the key in URL, so pivoted to that.

fastlane/fastlane#30206

Maybe you guys needed it for something else, but thought it would help. We were bite at same time.

[MattKiazyk]

Interesting using the /signout url - I had started a fix XcodesOrg/XcodesLoginKit#6 but didn't use that way

I am nervous of the stableness of this, but I guess Xcode's, fastlane, and all of the past have been hacking it together for a while.

[wkonury-an]

still dead :(

[knightbenax]

bug still here 😞

[MattKiazyk]

Should be fixed here. #492

I'll try to get a release out this weekend.

[MattKiazyk]

CLI v 2.1.0 is available with the fix