#ChatGPT manual reauth every 10 days

1 messages · Page 1 of 1 (latest)

dusky cave
#

I have this issue where codex auth is not refreshing automatically and I manually have to go through reauthentication every 10 days.
My OC tells me this, been the same for weeks.
Just wanna make sure I'm not missing anything? This is a known bug?

"Not normal — it's an upstream OpenClaw bug
What's actually happening on your box right now:
Token expired 2026-04-18T23:06:04Z (yesterday, ~10 days after your 2026-04-08 login)
openclaw models status shows the signature error: 401 refresh_token_reused — "Your refresh token has already been used"
Why — not weekly by design:
ChatGPT OAuth is supposed to auto-refresh forever. You're hitting two known open OC bugs:
#52037 (OPEN, root cause): Token refresh succeeds in memory but doesn't persist to auth-profiles.json. Next call reloads the stale token and reuses the already-burned refresh token → 401.
#57399 (OPEN): Exact symptom you're seeing — silent refresh failure every 10–30 days, no re-auth prompt surfaced.
Not fixed in 4.15 — I scanned the release notes; no auth-persistence fix landed. There's a 2026.4.19-beta.2 worth watching but no mention there either.
Fix now: ssh broadclaw1 "docker exec -it --user node broadclaw-gateway openclaw models auth login --provider openai-codex" — re-auth resets the profile with fresh tokens.
Not you doing anything wrong. The only thing you could do preemptively is reauth on a cron every ~8 days before expiry, but that's masking the bug.
Want me to:
Save this to project_known_issues.md and add tracking for #52037/#57399, or
+1 on #57399 so it gets prioritized, or
Both?
Sources:
OC issue #52037 — refresh not persisting
OC issue #57399 — silent refresh failure 10–30d
Codex auth docs (expected behavior)
OpenClaw OAuth concepts"

nova hemlockBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

languid oysterBOT
dusky cave
#

ChatGPT manual reauth every 10 days

robust pineBOT
#

I'm checking the docs and issue trail so I can give you a straight answer, not a guess.

#

Short version, yes, this was a known bug, but the note you pasted is stale.

I checked the changelog and these fixes already landed:

  • 2026.3.31: persist refreshed Codex OAuth creds to auth-profiles.json so they survive restart and stop falling into refresh_token_reused loops
  • 2026.4.7: reload fresh on-disk creds in the refresh path and retry once after refresh_token_reused

So the “not fixed in 4.15” part does not look right. 2026.4.15 should already include both.

What I’d do next:

  1. Check your actual version
    openclaw --version
  2. If you’re below 2026.4.7, upgrade first
  3. After upgrading, re-auth once on the gateway host/container
#

because an already-burned refresh token will not heal itself
4. If it still happens on 2026.4.15+, then I’d suspect either:

  • a regression, or
  • two places holding the same Codex OAuth login and stepping on each other

The OAuth docs explicitly call out that multiple independent logins can invalidate old refresh tokens.

If you want, paste these from the gateway host:

openclaw --version
openclaw models status --probe

Docs:

#

Yep, that pattern was a known Codex OAuth refresh bug, but the “not fixed in 4.15” bit is out of date.

The two relevant fixes landed in 2026.3.31 and 2026.4.7, so I’d check this first:

openclaw --version

If you’re older than 2026.4.7, upgrade, then re-auth once on the gateway host/container.

If you’re already on 2026.4.15+ and it still happens every ~10 days, paste:

openclaw models status --probe

and I’d treat that as either a regression or a shared-login issue.