GitHub Sign In redirects to http://127.0.0.1:35711/

[act28]

Reproduction steps

1. Click Sign In -> opens browser at https://zed.dev/native_app_signin?native_app_port=38319&native_app_public_key=....
2. In Firefox/Librewolf, link never redirects to Github.
3. In Chromium, logs into Github fine, but redirects to http://127.0.0.1:35711/ with user_id and token (which fails)
4. Zed never registers redirect url and user is not signed in: Error: didn't receive login redirect

Current vs. Expected behavior

Current behavior: user is not redirected from Github on successful sign in to app. Error: didn't receive login redirect
Expected behavior: user is redirected to zed.dev successful sign in page, and app receives redirect url with user_id and token

Zed version and system specs

Zed Version: v1.3.7+stable
OS: Linux 6.18.31-1-lts
Memory: 32GB
Architecture: amd64

Attach Zed log file

Zed.log

2026-05-26T04:03:32+00:00 INFO  [client] set status on client 0: Reauthenticating
2026-05-26T04:05:13+00:00 INFO  [client] set status on client 0: AuthenticationError
2026-05-26T04:05:13+00:00 ERROR [workspace::notifications] didn't receive login redirect

Relevant Zed settings

settings.json

Relevant Keymap

keymap.json

(for AI issues) Model provider details

No response

If you are using WSL on Windows, what flavor of Linux are you using?

Arch Linux

[zed-community-bot]

Additional recent context for triagers

Possibly related open issues:

• Zed auth callback returns 404 #35220 — Both issues show the same error 'didn't receive login redirect' and involve the OAuth callback failing. Issue Zed auth callback returns 404 #35220 mentions callback returns 404, while GitHub Sign In redirects to http://127.0.0.1:35711/ #57693 shows redirect to localhost fails. Both suggest the same underlying OAuth callback handling bug.
  • Possible shared root cause: OAuth callback redirect mechanism failing to properly handle the localhost redirect URL

Recently closed, possibly related:

• Zed account sign-in fails with "failed to decrypt access token" / "Invalid padding" on macOS #54994 (closed as not_planned) — Recently closed issue about sign-in failures on macOS with similar OAuth flow problems and localhost redirect issues, though with a different specific error ('failed to decrypt access token'). Useful context for OAuth-related authentication debugging.
• Zed auth callback returns 404 #35220 (closed as not_planned) — Previously reported issue with identical error message 'didn't receive login redirect' and OAuth callback problems, closed as not_planned. Shows this may be a known limitation or complex issue.

---

_{This is an automated analysis and might be incorrect.}

[yeskunall]

This has been reported several times in the past. Looking at your issue, however, there’s two distinct failure modes mixed together, and they probably have different root causes -- narrowing things down would help.

Firefox / Librewolf: the page at zed.dev/native_app_signin?... never forwarding to GitHub means the OAuth flow isn’t even starting, so the local-callback side of things is irrelevant here. A few things to check:

• Does that page render normally, or does it appear blank / stuck?
• Anything logged in the browser’s developer console (F12 → Console) when it loads?
• Librewolf in particular ships with strict tracking protection and some JS features disabled by default -- does it work if you temporarily allow zed.dev under about:preferences#privacy (or test in a fresh profile)?

Chromium: based on the log timestamps you posted, the gap between Reauthenticating (04:03:32) and AuthenticationError (04:05:13) is 101 seconds, which lines up almost exactly with Zed’s local-callback server timing out -- it polls 100 × 1s in crates/client/src/client.rs and then gives up with didn't receive login redirect --

zed/crates/client/src/client.rs

Lines 1481 to 1520 in 63ff997

	// Receive the HTTP request from the user's browser. Retrieve the user id and encrypted
	// access token from the query params.
	//
	// TODO - Avoid ever starting more than one HTTP server. Maybe switch to using a
	// custom URL scheme instead of this local HTTP server.
	let (user_id, access_token) = background
	.spawn(async move {
	for _ in 0..100 {
	if let Some(req) = server.recv_timeout(Duration::from_secs(1))? {
	let path = req.url();
	let url = Url::parse(&format!("http://example.com{}", path))
	.context("failed to parse login notification url")?;
	let callback_params: CallbackParams =
	serde_urlencoded::from_str(url.query().unwrap_or_default())
	.context(
	"failed to parse sign-in callback query parameters",
	)?;
	let post_auth_url =
	http.build_url("/native_app_signin_succeeded");
	req.respond(
	tiny_http::Response::empty(302).with_header(
	tiny_http::Header::from_bytes(
	&b"Location"[..],
	post_auth_url.as_bytes(),
	)
	.unwrap(),
	),
	)
	.context("failed to respond to login http request")?;
	return Ok((
	callback_params.user_id,
	callback_params.access_token,
	));
	}
	}
	anyhow::bail!("didn't receive login redirect");
	})
	.await?;

That can mean either:

1. The OAuth flow took just over 100s end-to-end (slow 2FA prompt?), so the browser’s redirect to 127.0.0.1 arrived after Zed had stopped listening.
2. The browser made the redirect request but it never reached the local server (loopback firewall rule, browser blocking localhost, etc.).

To tell those apart:

• Check what http://127.0.0.1:<port>/ actually shows in the Chromium tab after the GitHub authorize step -- “connection refused”, an empty page, an error page, or something else?
• Confirm whether you have any local firewall rules (iptables/nftables/firewalld) that might be filtering loopback traffic?
• If you can, retry and complete the GitHub flow as quickly as possible.

/cc @act28