Outcome: not planned — abandoned after root-cause investigation
After extensive live debugging (see full history in this issue's discussion), we found a hard platform limitation that rules out a 100%-static, no-backend implementation:
GitHub's /search/code REST endpoint does not include CORS response headers on its actual responses — even on a genuine, successful 200 OK.
This was confirmed with concrete evidence, not speculation:
- A real search request reached GitHub, authenticated correctly, and returned a legitimate
200 OK with code_search-specific rate-limit headers (X-Ratelimit-Resource: code_search, etc.) — proving the request fully succeeded server-side.
- That same successful response had no
Access-Control-Allow-Origin header at all, so the browser correctly blocked the page from reading it.
- This was reproduced consistently across multiple browsers, multiple networks, and a custom hostname (ruling out local security software, corporate proxies, and "localhost origin" theories that were investigated and eliminated along the way).
- The generic
OPTIONS preflight for github.com/ghapi does advertise CORS support broadly, and GitHub's own docs show CORS headers on other endpoints (e.g. /repos/.../issues) — but this doesn't extend to /search/code's actual data responses, which appear to be served by different, specialized backend infrastructure (consistent with the docs' own note that Search Code has stricter, different rate-limiting from other search endpoints).
No client-side code change can fix a response missing a CORS header — the browser enforces this regardless of retries, request headers sent, or hostname used.
Why this ends the initiative
The only way to work around a missing CORS header is a server-side relay that adds it — but the team explicitly does not want to introduce or maintain any server-side component, and especially does not want any user-supplied GitHub token transiting through a server piece, even a stateless one. Both are reasonable, firm constraints, and there is no remaining architecture that satisfies "live search, real GitHub API, zero backend, and the visitor's token never touches a server."
Disposition
- This EPIC and all 9 sub-issues are closed as not planned.
- No code was merged: all work happened on local, unpushed branches and has been discarded; no PRs were ever opened.
- If this is revisited in the future, any viable design must account for the CORS limitation documented above — a thin, secret-free relay (forwarding the visitor's own token, never storing it) is the minimum viable shape of a working solution, or alternatively fall back to a non-live, recorded demo (e.g. embedding the existing
demo/demo.gif) instead of live search.
Outcome: not planned — abandoned after root-cause investigation
After extensive live debugging (see full history in this issue's discussion), we found a hard platform limitation that rules out a 100%-static, no-backend implementation:
GitHub's
/search/codeREST endpoint does not include CORS response headers on its actual responses — even on a genuine, successful200 OK.This was confirmed with concrete evidence, not speculation:
200 OKwithcode_search-specific rate-limit headers (X-Ratelimit-Resource: code_search, etc.) — proving the request fully succeeded server-side.Access-Control-Allow-Originheader at all, so the browser correctly blocked the page from reading it.OPTIONSpreflight forgithub.laiyagushi.com/ghapidoes advertise CORS support broadly, and GitHub's own docs show CORS headers on other endpoints (e.g./repos/.../issues) — but this doesn't extend to/search/code's actual data responses, which appear to be served by different, specialized backend infrastructure (consistent with the docs' own note that Search Code has stricter, different rate-limiting from other search endpoints).No client-side code change can fix a response missing a CORS header — the browser enforces this regardless of retries, request headers sent, or hostname used.
Why this ends the initiative
The only way to work around a missing CORS header is a server-side relay that adds it — but the team explicitly does not want to introduce or maintain any server-side component, and especially does not want any user-supplied GitHub token transiting through a server piece, even a stateless one. Both are reasonable, firm constraints, and there is no remaining architecture that satisfies "live search, real GitHub API, zero backend, and the visitor's token never touches a server."
Disposition
demo/demo.gif) instead of live search.