Add WhenResets to the Stat section

[kosanhu2021-source]

Refs #129 — opened there as a suggestion, thanks for the go-ahead.

What this adds

One entry at the end of the Stat section, matching the existing format:

- [WhenResets](https://whenresets.net) - Sourced public ledger of every OpenAI Codex rate-limit reset: 55 records, each linking to the original announcement. Also published as MIT-licensed CSV/JSON.

Being upfront about your inclusion criteria

Your contributing.md is specific, so two things worth flagging rather than hoping you don't notice:

1. This is not a Codex CLI integration, and I'm not claiming it is. It's a data resource: it records when Codex rate limits were reset and cites a primary source for each one. The other Stat entries all read local logs to show current usage — the reset history doesn't exist in any local log, which is the gap it fills.
2. It doesn't have stars/downloads/community activity yet. The dataset is public (MIT, CSV + JSON) and the site is live, but adoption is early.

If either of those puts it out of scope, that's completely fair — feel free to close this and I won't re-submit.

Links

• Site: https://whenresets.net
• Dataset (MIT, CSV + JSON, 55 records): https://github.com/kosanhu2021-source/codex-reset-ledger

[milisp]

Can you add a section first,

Such as

⁠## Reset Trackers

[kosanhu2021-source]

Thanks for pushing that — a dedicated Reset Trackers section is better than burying it under Stat, and splitting it out reads well. The entry and the TOC anchor both look right to me.

Two things, either way is fine:

• If you'd rather the entry carried a second link, the dataset behind it is open (MIT, CSV/JSON): https://github.com/kosanhu2021-source/codex-reset-ledger
• If you want the wording tightened or the section filled out, say the word and I'll push it.

Not in a hurry — happy to leave it exactly as it is.

[milisp]

Looks good, thanks for the quick follow-up! I'll keep the entry as a single link — cleaner than doubling up with the dataset repo. Merging now.

[github-actions]

🎉 Thanks for the contribution, @kosanhu2021-source!

If you'd like more eyes on what you just shipped, feel free to submit it to ProductShip.lol — a free "just shipped" feed with upvoting.

[kosanhu2021-source]

Hi milisp — I took you up on the ProductShip suggestion and hit a blocker at the sign-in step. Reporting it because it looks like it affects everyone, not just me.

What happens

1. https://productship.lol/submit → "Continue with GitHub"
2. Authorize on GitHub → lands on http://localhost:3000/?code=131ed741-f2d6-4a34-929a-03a0949a8430
3. ERR_CONNECTION_REFUSED — nothing listens there.

Why (most likely)

Your app correctly sends Supabase:

redirect_to=https://productship.lol/auth/callback?next=/submit

That exact value is in the authorize URL, so the client call is fine.

Supabase only honours redirect_to when it matches an entry in Authentication → URL Configuration → Redirect URLs. Otherwise it silently falls back to the Site URL — whose default is http://localhost:3000. That matches exactly where I landed: the root path / (not /auth/callback) with ?code= appended — the classic fallback signature.

Two likely mismatches:

• the allow-listed entry is probably https://productship.lol/auth/callback with no wildcard, while the app appends ?next=/submit → no exact match
• Site URL is still the default http://localhost:3000, so that is the fallback target

I grepped all 9 of your client bundles (849 KB) for a hardcoded localhost: the only hit is the Supabase library's own localhost:9999 default. So this is dashboard config, not your code.

Fix (one settings page)

Authentication → URL Configuration:

• Site URL: https://productship.lol
• Redirect URLs: add https://productship.lol/** (the wildcard covers the ?next= query)

Evidence

client_id=Ov23lilszBvcHgHd9X8x
redirect_uri=https://ixqngtmhwundtguyqjgv.supabase.co/auth/v1/callback
redirect_to=https%3A%2F%2Fproductship.lol%2Fauth%2Fcallback%3Fnext%3D%2Fsubmit

Happy to re-test and confirm once it is changed — I'll submit WhenResets then.

— @kosanhu2021-source (the WhenResets PR you merged the other day)

[milisp]

Thanks for this one, @kosanhu2021-source — and for being upfront about the inclusion criteria rather than hoping I wouldn't check. That made the review easy, and the reset-history gap you described is a real one, so the entry belongs where you put it.

Also: thank you for the ProductShip sign-in report. Your diagnosis was correct — it was Supabase URL config, not the client code. Two corrections to the details, both in your favour:

• Site URL was still the default http://localhost:3000, exactly as you guessed.
• The redirect allow-list didn't have a too-narrow productship.lol entry — it had no productship.lol entry at all, so every variant fell back to the Site URL.

Both are fixed now (https://productship.lol + https://productship.lol/**), and I re-ran the full flow end to end: /submit → GitHub → authorize now lands on https://productship.lol/submit with a real session, instead of a dead localhost:3000.

I also found a second bug while in there, which your report is what led me to: the browser client and the server client were using two different Supabase keys (legacy anon JWT vs. the new publishable key). Fixed and deployed.

Sign-in works now, so WhenResets is clear to submit whenever you're ready. Thanks again for taking the time to write it up properly.

[kosanhu2021-source]

Thanks for the fast turnaround — and the corrections are the useful part. My guess was "allow-list entry too narrow"; "no entry at all" is the cleaner explanation, since it accounts for every variant of the callback falling back, not just the one carrying the ?next= query.

The second one is the more interesting find. Browser client on the legacy anon JWT and server client on the publishable key keeps working right up until something needs the two to agree — exactly the class of bug that never surfaces until someone walks the whole flow end to end. Glad it fell out of the same trip.

Verified the routing from outside: /auth/callback 307s to /auth/login?error=auth with no code, /auth/login serves 200, feed and /submit healthy. Submitting WhenResets now — thanks again for taking the report seriously.

[milisp]

Got it, thanks for confirming!