bug: Codex Session Logout Frequently

[blrcoderbro]

Affected area

None

What broke?

Codex sessions are logging out frequently.

Reproduction steps

No response

Expected behavior

No response

Actual behavior

No response

CCS version

No response

Operating system

None

Environment details

No response

Logs, screenshots, or terminal output

Before submitting

• I searched existing issues first.
• I removed secrets and private data from logs/screenshots.
• I can still reproduce this on the latest released or dev build.

[kaitranntt]

I could not prove a CCS-side root cause from the current report yet, so leaving this open as needs-repro. The code paths that could affect Codex auth are provider/profile selection and Codex token-file handling, but the report needs more concrete state to separate CCS behavior from Codex CLI/session behavior.

Please add:

• ccs --version
• Exact command/path where logout happens: ccsx, ccsxp, ccs codex --target codex, or plain codex
• Whether the two terminals use separate CCS/Codex profiles or the same profile
• What "logged out" means exactly: Codex auth prompt, missing auth.json, account changed, or provider request rejected
• Redacted output from ccs codex auth show --json and any relevant CCS/Codex log line around the logout

Once those details are available, I can pin this to the responsible path and patch it instead of guessing.

[blrcoderbro]

I'm using the latest dev version.
I see a re-auth badge in the CCS dashboard.

[kaitranntt]

Thanks. latest dev moved during the release work today, so please confirm against ccs --version showing 8.1.4-dev.1 or newer.

The dashboard re-auth badge is useful, but by itself it only tells us CCS could not verify the Codex auth profile from its local auth state. It does not yet prove whether native Codex is actually logged out, whether the active profile is wrong, or whether the dashboard decoder is missing a newer Codex auth.json shape.

Please add these exact checks while the badge is visible:

• ccs --version
• Which command still works/fails without login: codex, ccsx, ccs codex --target codex, or ccsxp
• ccs codex auth show --json with tokens/paths redacted if needed
• Whether native codex works from the same terminal while the dashboard says re-auth
• Redacted key shape only for the active auth file: top-level keys and tokens keys, not token values

With that I can separate a real session invalidation from a dashboard false-positive and patch the right layer.

[kaitranntt]

Investigation: Codex re-auth badge appears frequently

Traced both layers that can drive the dashboard re-auth badge. The badge is not raised by a timer or a heuristic — it is raised only when the on-disk Codex auth file is read as past its expired timestamp:

• src/cliproxy/auth/auth-utils.ts:56-59 — isTokenExpired returns expiredAt < Date.now() with no clock-skew grace and no check of whether the proxy daemon is actively managing the file.
• src/cliproxy/auth/quota-fetcher-codex.ts:648-656 — when isExpired is true the fetcher sets needsReauth: true, which the dashboard renders as the badge.

On the proxy side the refresh path looks healthy:

• sdk/auth/codex.go:34-36 — RefreshLead is 5 days, and the auto-refresh loop runs every ~5s, so the on-disk expired should never go stale while the daemon is running.
• internal/auth/codex/openai_auth.go:277 — RefreshTokensWithRetry (3 attempts) persists a fresh expired after each successful refresh, and is correctly non-retryable on invalid_grant / refresh_token_reused.

So there are two distinct causes that produce the exact same badge, and they cannot be told apart from the current report:

1. Real session invalidation (not a CCS bug). If the refresh token is revoked upstream (invalid_grant / refresh_token_reused / 401), refresh stops rewriting the file, expired goes stale, and the badge fires correctly. Fix is to re-auth — nothing for CCS to change.
2. Dashboard false-positive (CCS bug). If the proxy daemon is not running (so the 5s refresh loop is not keeping the file fresh), or there is a clock/format skew, the badge fires even though native codex still works.

Why a blind fix is risky: adding clock-skew tolerance or suppressing the badge would mask cause #1 — a genuinely invalidated session — which is worse than the current behavior. A prior speculative patch in this area was already reverted once.

To proceed, please attach (redact secrets):

1. ccs --version
2. ccs cliproxy auth codex show --json (or the auth-file key shape) — specifically the expired value vs. your current local time
3. Whether native codex still works at the moment the badge is showing
4. Whether the CLIProxy daemon is running when the badge appears (ccs cliproxy status / is the proxy process up)

Item 4 is the deciding signal: if the daemon is up and the badge still fires, it points to a CCS-side false-positive; if the daemon is down (or the refresh token was revoked), the badge is correct. Keeping needs-repro until this data lands.

[kaitranntt]

Still need one piece of data to separate a real session invalidation from a dashboard false-positive, since both raise the same re-auth badge.

The badge is set when the on-disk Codex auth file is read as past its expired timestamp. That happens in two distinct situations:

1. The refresh token was actually invalidated upstream (revoked, reused, or 401). The badge is correct and the only fix is to re-auth.
2. The CLIProxy daemon was not running, so the background refresh loop did not keep the auth file fresh, or there is a local clock/format skew. The badge then fires even though native codex still works.

The deciding signal is item 4. Please capture, with secrets redacted, while the badge is showing:

1. ccs --version
2. The auth file expired value vs your current local time
3. Whether native codex still runs from the same terminal at that moment
4. Whether the CLIProxy daemon is up at that moment (ccs cliproxy status)

If the daemon is up and the badge still fires, it points to a CCS-side false-positive we can patch with clock-skew tolerance. Without item 4 a fix risks masking a genuinely invalidated session.