GitHub Mobile App and Browser Trapped in an Infinite Redirect Duel

Level 1: Two Overly Polite Doormen

Imagine two doormen at neighboring doors, each insisting the other should serve you. "He'll help you!" — "No, he'll help you!" — and they keep spinning you back and forth between them, very politely, forever. You never get inside either door. That's the whole joke: the phone's app and the phone's browser each think the other one should show the page, so the poor user just bounces between them like a ping-pong ball. The character's dead-eyed stare is what your face looks like by the fourth bounce.

Level 2: The Machinery of the Ping-Pong

• Deep link — a URL that opens a specific screen inside an app instead of a website (e.g., a GitHub issue link opening the app's issue view).
• Universal links / app links — the iOS and Android mechanisms that let an OS say "URLs from this domain belong to this installed app." Great when it works; a boomerang when the app can't actually render the page it claimed.
• Redirect loop — A sends you to B, B sends you back to A. Browsers detect this inside a single tab; nothing detects it between an app and a browser.
• GitHub issue — a bug report or task on GitHub; the thing our blob friend was naively trying to read, presumably while away from a real keyboard.

The relatable rookie moment: tapping a link from chat, watching the screen flash app → browser → app like a strobe light, and finally long-pressing the link to copy it, opening an incognito tab, and reading the page logged-out like some kind of medieval peasant. Everyone has a workaround; nobody has a fix.

Level 3: Livelock, Now Shipping on Mobile

The blank-faced rage-comic blob holding a pistol to its own head — the venerable "Computer Suicide" template — is reserved for a specific tier of suffering: not catastrophic failure, but small, perfectly engineered futility. The captions nail one of mobile's most enduring sins:

*TRIES TO OPEN UP ISSUE IN GITHUB MOBILE APP* APP OPENS UP BROWSER, BROWSER AUTO REDIRECTS GITHUB LINK TO THE APP

What's being described is, technically, a livelock — the lesser-known sibling of deadlock. In a deadlock, two processes freeze waiting on each other. In a livelock, both stay busily, energetically active while making zero progress: two people in a hallway mirroring each other's sidesteps forever. Here the GitHub mobile app decides this particular issue view is better served by the browser and fires the URL outward; the browser's universal link / app intent handling sees github.com, consults the OS association table, and dutifully bounces the link right back into the app. Each component is behaving correctly by its own spec. The composition is a perpetual-motion machine of unhelpfulness, with the user as its bearing grease.

The deeper engineering truth: deep linking is a distributed handoff protocol with no coordinator. The app's internal router ("do I have a screen for this URL?"), the OS's link-association layer (verified app links, user preference flags, per-app "open supported links" toggles), and the website's own Open in app interstitials all make independent decisions based on independent state. Nobody owns the end-to-end path. So when the app's router doesn't recognize a URL shape — a new issues view, a query parameter, a project board — it punts to the browser, unaware that the OS will immediately punt it back. There's no TTL on the bounce, no loop counter, no equivalent of ERR_TOO_MANY_REDIRECTS for inter-app handoffs. HTTP solved this for redirects decades ago; the app/browser boundary never did.

And the organizational layer, which is why this stays broken: the failure lives between teams. The mobile team's metrics say the app opened successfully. The web team's metrics say the link resolved. The OS vendor's API behaved as documented. A bug with three owners has zero owners — and the only component that experiences the full loop is the human, who files the bug report... by trying to open an issue. In the app.