[Bug]: Managed ChatGPT conversations keep failing after token renewal until T3 restarts#16132

Triage

Thanks for the detailed report and trace, @chrhicks! It made this easy to follow end to end.

What I found

Managed ChatGPT sign-in renews the saved access token, but conversation traffic keeps going through the app-server process that was started with the old token. Only a restart picks up the new one. This still happens on main (31f9d832).

• CodexChatGptAuth.access refreshes when the saved token is within 60 seconds of expiry and writes the new tokens back (apps/server/src/provider/CodexChatGptAuth.ts).
• makeCodexManagedRuntime puts that token in the child environment as ACCESS_TOKEN and returns it as revision, but nothing reads revision afterward (apps/server/src/provider/CodexManagedRuntime.ts).
• CodexAdapterV2.openSession resolves the runtime once and spawns app-server with that environment. startTurn reuses the client captured at open (apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.ts).
• The registry's withAccess wrapper only covers openSession (apps/server/src/orchestration-v2/ProviderAdapterRegistry.ts). Provider status checks call withAccess(runtime.resolve) separately (apps/server/src/provider/Drivers/CodexManagedProvider.ts), so Settings can renew credentials without touching the live process.
• ProviderSessionManager keeps returning the existing runtime for the same provider session (apps/server/src/orchestration-v2/ProviderSessionManager.ts). Sessions are released on sign-in and sign-out (ProviderAuthService.stopSessions), not on a silent refresh.

Your October 5 trace matches this. App-server was spawned at 16:05:28 with the earlier token, and turns failed with 401 token_expired at 16:22. The exchange succeeded at 16:28:32, but no new app-server was spawned, so the next turn failed the same way. After the desktop restart, thread/resume worked. Refreshing or toggling the provider doesn't release the session the manager is already holding, which is why that didn't help. Restarting T3 is the workaround for now.

This is separate from #14356, where the refresh request itself fails with invalid_grant, and from #11136, which is about switching an existing Codex CLI account.

Likely fix area

OpenAI's Codex app-server token-sharing guide describes this flow: refresh the token, restart app-server with the new ACCESS_TOKEN, initialize, then thread/resume the saved thread. Possible directions:

• Watch the runtime revision and restart the managed app-server and resume the thread when the token changes, including when a turn is already in flight.
• Release the held provider session when a managed token refresh succeeds, so the next turn reopens with the new token.

A maintainer will decide on the fix direction.

Additional report of the same restart-recovery behavior on macOS, with sanitized local evidence from a newer nightly.

Environment

• T3 Code (Nightly): 0.0.46-nightly.20261011.2994 (installed version when investigated).
• macOS: 26.5.2.
• Codex CLI: 0.162.1, verified using the executable backing T3's currently running Codex app-server. These versions describe the inspected environment; the executable version at each earlier failure was not independently captured.
• The running backend uses T3's openai_token_sharing provider, with env_key="ACCESS_TOKEN", requires_openai_auth=false, wire_api="responses", and supports_websockets=false. No token values are included here.

Observed sequence

This describes recurring observed behavior, not a controlled deterministic reproduction:

1. Use Codex in T3 and keep the application running.
2. A conversation fails with 401 Unauthorized and token_expired; the timing appears variable to the user. No fixed token lifetime or sleep/wake trigger has been established.
3. The user reports that restarting T3 restores access without signing in again.

Sanitized log evidence

Local T3 provider logs show incoming codex.app-server error events with this response:

The captured incident progresses through Reconnecting... 2/5, 3/5, 4/5, and 5/5, each with 401 token_expired, before a final error with willRetry=false and a turn/completed event with status=failed. Similar incoming expired-token errors appear in multiple conversation logs on the same day. This is more than a single transient failure.

The repeated failures and failed turn are confirmed by logs. Recovery after restarting is the user's observation; a paired pre-/post-restart trace was not collected. Successful token renewal was not independently verified in this investigation.

Expected behavior and impact

Token renewal or credential reload should allow conversations to continue without restarting the application. Reconnect attempts should recover from expired authentication, or give an actionable authentication error if renewal genuinely cannot succeed.

This interrupts ongoing work and requires restarting T3 as a workaround.

Investigation lead (not a confirmed root cause)

The currently running Codex process receives an access token through an environment variable rather than Codex-managed OpenAI authentication. A running process does not automatically receive later environment changes. Please investigate whether token renewal updates/recreates the relevant backend or transport, and whether expired-token failures trigger credential reload and recovery. Restart recovery is consistent with stale process authentication state, but does not establish it as the cause.

Also related: #17445, which reports expired-token failures during long Codex runs on macOS.

Local paths, usernames, hostnames, account details, conversation/session/turn IDs, exact incident timestamps, request IDs, Cloudflare identifiers, and all credential values have been omitted. No raw logs or screenshots are attached.

Additional reproduction on Linux

I observed this again on T3 Code 0.0.46-nightly.20261012.3021 (Linux x64), with Codex CLI 0.156.1. T3 launched the Codex app-server using its openai_token_sharing provider configuration and an ACCESS_TOKEN environment mapping; the credential value is not included.

Two turns in one Codex thread failed against /v1/responses with 401 token_expired:

• 2026-10-12T20:20:55Z: request req_24fcd79ce1aa413a87be792a324c7980, cf-ray a498ce138b48471f-BOM
• 2026-10-12T20:31:25Z: request req_df33d79dc7f345dc9df8a406dc73d37b, cf-ray a498de30d9d1493a-BOM (the UI reported “Provider error after 5/5 retries”)

A separate Codex thread on the same host also had a failed run with token_expired earlier that day, at approximately 2026-10-12T12:39Z.

Restarting the Codex provider did not recover the affected thread (user observation). Fully restarting T3 at approximately 2026-10-12T20:32Z did; the next two turns in that thread completed without signing in again.

This is consistent with the session-refresh explanation in the triage comment above. I do not have an auth-store trace proving that a credential refresh succeeded during this specific incident, so this is a recurrence report rather than independent proof of the refresh step. No token values or raw logs are attached.

Confirmed again on T3 Code Nightly 0.0.46-nightly.20261013.3053, Windows x64, managed Codex 0.156.1, model gpt-6.1-sol. This capture measures the token expiration in the live child's environment and compares it with T3's saved credential. It also verifies recovery by releasing only the stale provider session, without restarting T3 or completing a new sign-in.

Observed timeline

All times are UTC on October 13, 2026.

The renewal happened after the two failed turns. We did not send an additional request to the stale child after renewal. Continued use of A at 18:26:45 is established by reading the live child's ACCESS_TOKEN and comparing it locally with the saved connection. The successful probe is a recovery control; it does not validate a permanent fix or another hour-long run.

Installed code

The server bundle extracted from the running Windows installation is apps/server/dist/binCli-_y10HK6w.mjs, 13,532,569 bytes, SHA-256 3f4e8567d80dbe4eb017bdfe14f8d3d3007a053a93d95ce2647bb7470e13c371.

Its source regions match the diagnosis above:

• CodexManagedRuntime.ts calls auth.access, supplies ACCESS_TOKEN at launch and returns an unused token revision.
• CodexAdapterV2.ts resolves the managed runtime in openSession; later turns reuse that client.
• CodexChatGptAuth.ts renews only within 60 seconds of expiration. This allowed the initial child to launch with less than seven minutes remaining.
• Failed 401 turns retain the shared session. Successful saved-token renewal does not release it.

This also covers #17445's case of a running turn reaching token expiry. The current token is renewable; another sign-in is unnecessary for this incident. Releasing the stale session restored Codex while unrelated Claude work continued. Starting and immediately cancelling authentication is a diagnostic workaround, not a proposed user-facing recovery flow.

Posted by Codex on Jonathan's behalf. Account identities, local paths, conversation IDs, credential values and raw logs are omitted.

Also seen on macOS, nightly 0.0.46-nightly.20261014.3118

Same symptom on T3 Code Nightly 0.0.46-nightly.20261014.3118, macOS (Apple silicon), managed Codex 0.156.1, model gpt-6.1-sol. T3 started the app-server with the openai_token_sharing provider. No other Codex client was running.

Timeline on Oct 14, 2026, US Central time:

• 20:26:01: T3 is restarted, and a new codex app-server starts as T3's child. Requests work.
• 20:40:10: the app-server's codex_login::auth::manager runs a refresh.
• 20:40:21: ~/.codex/auth.json is rewritten with a new last_refresh.
• About 20:40:30 onward: every request from that app-server fails with 401 Unauthorized … auth error code: token_expired.
• Recovery: the logs show auth_recovery_mode="managed", auth_recovery_phase="reload", auth_recovery_outcome="recovery_succeeded", but the follow-up request is still 401 (auth_recovery_followup_success="false"). Only a full T3 restart recovers.

The same pattern happened about five times today (around 16:19, 17:21, 18:37 and 20:40). Each time, a credential renewal was followed by persistent 401s in the already-running app-server until T3 was restarted. That fits this issue's description: the live child keeps using the pre-renewal token after T3 (or the child) renews.

Ruled out:

• Disabling the node_repl MCP server and the unified computer-use plugin. That removed a second Codex client that had also been refreshing the shared login, but the issue remains with T3 as the only client.

Additional recurrence on Windows x64, T3 Code server 0.0.46-nightly.20261015.3158. This matches the restart-recovery symptom in this issue, so I am adding evidence here rather than opening a duplicate.

What happened / observed sequence

1. Use managed Codex in T3 and leave T3 running.
2. Conversation requests start failing with 401 token_expired. All five reconnect attempts fail, followed by a failed turn.
3. The user reports that restarting T3 reliably restores requests temporarily without signing in again.

These are recurring observations, not a new deterministic reproduction. Successful OAuth renewal during these particular incidents, the saved-token/child-token comparison, and paired pre-/post-restart traces were not independently captured.

Sanitized evidence

The local provider protocol log confirms this sequence on October 15, 2026 (UTC):

The error is:

An earlier conversation log confirms the same five-retry pattern on October 14 at 14:02:18.312–14:02:23.829 UTC, then willRetry=false at 14:02:27.567 UTC. The installed server version above was confirmed for this investigation, not independently for the previous day's incident.

The live app-server launch configuration uses openai_token_sharing, env_key="ACCESS_TOKEN", requires_openai_auth=false, wire_api="responses", and supports_websockets=false. No credential values or full logs are included.

Source cross-check

I checked current upstream main at 42da166d131017335a1158d0b379dd68b8985796:

• CodexManagedRuntime.ts still supplies ACCESS_TOKEN in the launch environment and returns the token as revision.
• CodexAdapterV2.openSession resolves that runtime at session open and captures the client.
• ProviderSessionManager.open returns an existing runtime without checking the credential revision.
• CodexChatGptAuth.access can renew and save credentials. Updating that store cannot update an already-running child's environment.

This corroborates the existing maintainer diagnosis; it does not independently prove that a refresh succeeded in this user's incident. OpenAI's app-server token-sharing guide requires the host to renew, restart the env_key app-server with the new token, initialize, and resume the saved thread.

Existing fixes / scope

I found open #16849 (replacement before the next turn) and #19895 (native auth.command renewal, including active turns), as well as related #17445. I have not opened a competing PR or claimed either existing PR is verified by this report. No source patch, regression test, live credential manipulation, or installed-app modification was performed.

Screenshot

A user-authorized screenshot confirms “Provider error after 5/5 retries” and the exact error above. I prepared a crop containing only that error, removing local paths and unrelated tool history. The connected GitHub tool has no attachment-upload operation and the available GitHub browser session is signed out, so the image is not attached here; no broken local URL or repository-hosted evidence asset is included.

Reported on behalf of @waLLxAck; investigation and writing by GPT-6.1 Sol (high reasoning effort), Codex harness through T3 Code.

Confirmed on stable v0.1.0 (Linux, systemd service)

Still happening on the v0.1.0 release, with managed "Connect with ChatGPT" sign-in (setupMode: "managed"). It matches the root cause already described here: the shared app-server gets ACCESS_TOKEN once at spawn and never receives a renewed token.

Environment

• T3 Code server 0.1.0, running as a systemd user service (t3code.service). The app-server runs in its own t3code-codex-*.scope.
• Debian 13, kernel 6.12, x64
• Codex CLI 0.163.0
• Two Codex instances: one managed (affected) and one default ~/.codex login (not affected).

Timeline (UTC, 2026-10-16)

The iat/exp values come from decoding the JWT claims of ACCESS_TOKEN in the live app-server's environment. The token itself was not logged.

The app-server was spawned with a token that was already 40 minutes into its 1-hour life. That fits auth.access returning the saved token unchanged until it is within 60 seconds of expiry. So the effective lifetime of a new app-server can be much shorter than an hour.

Stopping only the app-server is not a workaround on v0.1.0

I stopped just the stale managed app-server with systemctl --user stop t3code-codex-<id>.scope. The shared provider session kept its client to the dead process:

• The next turn failed in orchestrationV2.deliverContextHandoffs with Failed to inject historical context, caused by CodexAppServerProcessExitedError: Codex App Server process exited with code 0. That is the injectHistory path in CodexAdapterV2.ts.
• A second retry failed the same way (Codex App Server process exited with code 0), so the dead session isn't discarded after an error either.
• Meanwhile, provider status probes against a freshly spawned app-server succeeded.

Working workaround: systemctl --user restart t3code.service. Conversations work again without signing in again.

Related: #17445, PR #19895.

Produced via t3 triage with Claude Code (Claude Opus 5.5).

Another occurrence on stable v0.1.0, Windows 11 x64, managed Codex (setupMode: "managed", Codex 0.162.1, model gpt-6.1-sol), during a delegated task. Codex's own logs and T3's server trace add two details to the existing diagnosis.

1. The app-server started with a token that had less than 5 minutes left. auth.access returns the stored token unchanged while more than 60 seconds remain (CodexChatGptAuth.ts:730). So a long-running process can start with a token that is about to expire. Nothing replaces that token afterwards.

2. Codex's built-in 401 recovery refreshes a different credential. With an empty homePath, the managed runtime uses the shared default Codex home, which also holds a CLI ChatGPT login. On the 401, Codex refreshes that login's auth.json and logs recovery_succeeded. But the request is authorized by the ACCESS_TOKEN launch variable, so Reloaded auth, changed: false follows, and the retry fails again. The logs make it look as though recovery worked.

Timeline (relative to app-server start)

Excerpt (redacted, times relative to the first 401):

The code involved is the same on current main: the static ACCESS_TOKEN (CodexManagedRuntime.ts:94), the 60-second renewal window, and an unread revision. Between v0.1.0 and main, these files only had comments removed.

Investigated and written with Claude Opus 5.5 in Claude Code.

Confirmed again on T3 Code Nightly 0.1.1-nightly.20261018.3315, macOS 27.0.1 (26A434), with managed ChatGPT sign-in and Codex 0.162.1, model gpt-6.1-sol.

Observed behavior

An existing conversation was working through a managed ChatGPT account. A turn started at 2026-10-18 19:23:26 UTC, continued producing output and executing tools, then failed at 19:40:07 UTC with:

The provider still appeared healthy in T3. Local provider-status cache inspection after the failure found status: "ready" and auth.status: "authenticated" for that same managed account, checked at 19:42:49 UTC. The native provider log also captured another turn on the same shared provider session retrying through Reconnecting... 1/5 to 5/5, all with expired-token 401s, before failing at 19:40:49 UTC.

Fully quitting and reopening T3 restored access, confirmed by the user. No new sign-in was needed for that recovery. This is an observed incident and restart recovery, not a controlled token-expiry reproduction. The approximately 17-minute duration of the failed turn is not a measurement of token lifetime.

Investigation

Inspection of the installed Nightly server bundle still shows the static managed-token path described in the triage above:

• makeCodexManagedRuntime sets ACCESS_TOKEN from credentials.accessToken and configures openai_token_sharing.env_key="ACCESS_TOKEN" with requires_openai_auth=false.
• CodexAdapterV2.openSession resolves that runtime and supplies its environment when opening the app-server client.
• The managed provider's status check independently calls withAccess(runtime.resolve) and supplies managed authenticated status to checkCodexProviderStatus.

This is consistent with the existing diagnosis: a health check can use current saved credentials while the running conversation process retains an older token. This investigation did not compare the live process token against the saved token or read either token's expiry, so it does not independently prove that comparison for this incident. Server traces include successful CodexChatGptAuth.exchange operations near the incident, but those spans do not identify the provider instance and are not attributed to this account here.

Expected behavior and impact

Managed conversations should recover from token expiry without an application restart, including during an active turn. The healthy indicator should not conceal a provider session that repeatedly fails authentication.

The failure interrupted ongoing work. Restarting the app is a confirmed workaround for this occurrence.

No raw logs, credentials, account emails, local filesystem paths, conversation identifiers, or project content are attached. Posted by a Codex agent at the user's request, based on local logs, installed-code inspection, and the user's recovery confirmation.

I'm just commenting to signal this issue is seriously annoying, and I'm also facing it.

T3 Code client version: 0.1.0 Provider: codex Protocol: codex.app-server

08:11:42.088Z Reconnecting... 1/5 HTTP 401, token_expired 08:11:43.113Z Reconnecting... 2/5 HTTP 401, token_expired 08:11:44.402Z Reconnecting... 3/5 HTTP 401, token_expired 08:11:46.125Z Reconnecting... 4/5 HTTP 401, token_expired 08:11:48.461Z Reconnecting... 5/5 HTTP 401, token_expired

08:11:53.220Z error message: unexpected status 401 Unauthorized: Provided authentication token is expired. Please try signing in again. url: https://api.openai.com/v1/responses cf-ray: a4ce5086df8923b9-BUD request id: req_9396029959424afe909a6842554b9c69 auth error: 401 auth error code: token_expired codexErrorInfo: other additionalDetails: null willRetry: false

08:11:53.229Z turn/completed status: failed durationMs: 1042893

Also hitting this on T3 Code 0.1.0 (systemd service, Linux arm64), managed ChatGPT sign-in, Codex CLI 0.156.1, model gpt-6.1-sol.

Both failures landed about 60 minutes after a managed app-server launch, and the stored credentials were fine the whole time:

So the saved login renews fine. The running app-server keeps the ACCESS_TOKEN it got at launch (CodexManagedRuntime.ts), and nothing restarts it or hands it the renewed token. Signing in again only helps because it restarts the session. The revision: credentials.accessToken field on the runtime is set but never read.

#21420 (auth.command) looks like it covers this case.

Confirmed recurring failures on T3 Code Nightly 0.1.1-nightly.20261019.3360, build commit 1451e7cb23034d29774338608368a15d8845df36, macOS 26.3.1, arm64, using a separate managed Codex instance with ChatGPT sign-in.

This is still interrupting daily work on this nightly. The user repeatedly has to reconnect or restart T3.

Observed evidence

Incoming codex.app-server events for the managed instance show repeated failures on October 18 and October 19. One captured sequence on 2026-10-19 (UTC):

The same managed instance has another terminal 401 token_expired at 15:05:32.751Z that day.

Credential inspection during the investigation found a one-hour managed access token (exp - iat = 3600), a saved refresh token, and the offline_access and chatgpt.tokens.use.direct scopes. No credential values are included here. A successful refresh during each failure window was not independently captured, so these observations alone do not establish that specific step.

Installed-build source check

The installed bundle was checked against the build commit above:

• CodexManagedRuntime.ts puts credentials.accessToken in the child's ACCESS_TOKEN environment and returns it as revision at line 109.
• CodexChatGptAuth.ts handles refresh near expiry and saves replacement credentials.
• The installed adapter resolves the managed runtime in openSession; startTurn reuses the captured app-server client. The bundle has no consumer that uses the returned credential revision to replace that live process.

This matches the already-triaged stale-child-token mechanism. Recovery needs to cover both subsequent turns and a single active turn outliving the token, without replaying already-completed tools. #21420 appears to target that mechanism; it is still open and unmerged at the time of this report.

The separate existing-CLI account-switch problem observed on the same host is being reported under #11136 rather than conflated with managed token renewal.

Posted by Codex on behalf of the account owner. Only sanitized protocol excerpts and expiry metadata are included; no raw transcripts, credentials, account identities, local paths, or conversation identifiers are attached.

Additional exact recurrence on Linux with a systemd user service.

Environment:

• Ubuntu 24.04, amd64
• T3 Code 0.0.45
• Codex CLI 0.156.1
• managed ChatGPT sign-in
• model gpt-6.1-sol
• T3 remained active with no automatic service restarts

Observed sequence on 2026-10-20 UTC:

1. A managed Codex turn failed with the same 401 Unauthorized / token_expired error.
2. Provider settings still displayed the managed ChatGPT account as authenticated.
3. The user reauthenticated the same saved account through Settings -> Providers.
4. A no-tools recovery probe completed successfully at 04:40:05Z in 7,165 ms.
5. The next long turn then ran for 3,214,593 ms (about 53m 35s) and failed at 05:39:02Z.
6. Its final retry sequence ran from 05:38:54Z through 05:38:58Z (Reconnecting... 1/5 through 5/5), with every request returning token_expired.
7. The user manually restarted the T3 background service at 05:42:29Z. The service returned active; post-restart inference has not yet been claimed as verified.

This matches the existing diagnosis: reconnecting replaces the saved credential and allows a fresh short-lived app-server to work, but a long-running app-server keeps the launch-time ACCESS_TOKEN and eventually crosses its expiry. Reauthentication therefore recovered a short probe but did not prevent recurrence during the next long turn.

The interrupted repository worktree and changes remained intact. Account identity, repository identity, filesystem paths, token values, request IDs, and the provider screenshot were intentionally omitted.

This appears to overlap the active-turn scope of #17445 and open PR #21420.

Also occurring on two connected Macs using T3 Connect.

• T3 desktop: 0.1.1-nightly.20261017.3238
• Remote managed Codex: 0.156.1
• Model: gpt-6.1-sol

The remote Mac remains connected. Settings → Providers shows Authenticated, including after refreshing provider status.

However, multiple existing threads and a subagent fail with:

The coordinator and subagent exhausted all 5 retries. This recurs and interrupts ongoing remote work despite the connected/authenticated status.

Please investigate stale authentication in existing provider sessions and recovery without repeatedly signing in.

Successful token renewal and recovery after restarting have not been independently verified in this incident.

Another occurrence on Linux x86_64, with a paired failure/restart/recovery observation on 2026-10-21.

Environment

• T3 backend: 0.1.2-nightly.20261021.3457, running as a systemd user service. The live backend executable was identified both before and after the restart; the service launcher itself points to an older installed version.
• Codex: 0.156.1, verified from the executable of the replacement app-server after recovery.
• Managed token-sharing configuration: the replacement app-server uses openai_token_sharing and has an ACCESS_TOKEN launch variable. Only presence/configuration was inspected for this check; no credential values were printed.
• A Windows T3 client connects to this Linux backend.

Observed sequence (UTC)

1. 09:07:09 — The affected conversation's initial run ended in failed. The UI showed “Provider error after 5/5 retries” with:
   text

   1	unexpected status 401 Unauthorized:
   2	Provided authentication token is expired. Please try signing in again.
   3	url: https://api.openai.com/v1/responses
   4	auth error: 401
   5	auth error code: token_expired

2. Before recovery, T3's provider configuration reported Codex as ready, despite the failed conversation. No Linux conversations had an active run.
3. 09:11:31 — Restarted the Linux backend with systemctl --user restart t3code.service. No new ChatGPT sign-in or manual credential edit was performed.
4. 09:12:29 — A minimal, no-tools authentication check in the same existing conversation, with the same GPT-6-Astra/high selection, completed successfully. The durable run status was completed, and the provider session was ready.

This confirms restart recovery in this incident, including an actual successful model response rather than just a healthy provider probe. We did not independently establish successful token renewal before the failure, compare old/new token values, or run across another token-expiry interval. This is a workaround observation, not verification of a permanent fix.

Posted by a Codex agent at the user's request, based on the user's screenshot and direct backend/runtime inspection. Private project details, host addresses, conversation IDs and credential values are omitted.

Regression evidence after the Beta / 0.1.0 update

@juliusmarminge @t3dotgg — I reproduced this again on the same managed-ChatGPT Linux backend after updating to the new Beta/0.1.0 path. The new evidence shows both the original stale-token bug and a re-auth failure mode that can leave the provider with no usable session.

Environment

• Desktop client: T3 Code (Beta) 0.1.0 on macOS arm64 (embedded build 9f62873bf195e4d8a762d768a1405a5f2f7b1697)
• Remote backend: T3 server 0.1.0, Ubuntu 24.04 amd64, running as a systemd user service
• Managed Codex: 0.156.1, ChatGPT sign-in
• Model: gpt-5.6-sol

The live managed app-server still launches with:

There is no auth.command. The installed Beta bundle also still sets ACCESS_TOKEN: credentials.accessToken in CodexManagedRuntime and returns a revision that is not used to update the running child. No credential values were read or included.

Verified timeline (UTC, 2026-10-21)

1. 08:21:10 — CodexChatGptAuth.exchange succeeds.
2. 08:33:19–08:33:42 — three turns through the existing managed child each exhaust Reconnecting... 1/5 through 5/5, then fail with 401 token_expired.
3. 08:34:10 — a manual auth flow calls ProviderAuthService.stopSessions; at 08:34:21 a replacement app-server is spawned.
4. 09:34:13–09:34:21 — a turn that had run for 1,508,300 ms (about 25m 8s) reaches expiry, exhausts all five retries, and fails.
5. 09:44:01 — another CodexChatGptAuth.exchange succeeds.
6. 09:44:09–09:44:17 — a new turn on the still-running child immediately exhausts all five retries and fails with the same 401 token_expired. This is direct evidence that a successful saved-credential refresh does not reach the live app-server.
7. 10:50:05 — another background exchange succeeds.
8. 10:50:40 — manual re-auth starts. ProviderAuthService.stopSessions succeeds immediately, but CodexChatGptAuth.authenticate remains pending for 299,994.8 ms and is then interrupted. No replacement app-server is spawned by this failed flow.
9. 11:07:43 — a separate desktop ChatGPT handoff successfully adopts credentials and stops sessions; a new managed app-server finally appears at 11:07:49.

The important regression in steps 8–9 is that re-auth tears down the only provider session before authentication has completed. When the auth flow hangs or is cancelled, the provider has neither the old session nor a replacement that can start with the already-refreshed saved credential. In this incident it remained unusable for more than 17 minutes until a separate desktop handoff completed. Previously, reconnecting and sending continue was at least a workable recovery; on this Beta, the failed re-auth attempt can make recovery worse.

This does not mean every Beta re-auth fails: the later desktop handoff succeeded. The reproducible failure is the destructive ordering plus lack of rollback/restart when authentication does not complete.

Implementation request

Could the fix cover both sides of this lifecycle?

1. Replace the static launch-time ACCESS_TOKEN with Codex's native auth.command (or equivalent) so an active app-server can obtain the current T3-owned token after refresh. This is the direction already implemented in #21420, but that PR is currently conflicting and unmerged.
2. Do not stop the current provider session until replacement credentials have been successfully exchanged, validated, and adopted. If authentication times out, is cancelled, or fails, preserve/restart a session from the current saved credential instead of leaving the provider empty.
3. After a successful credential handoff, either invalidate/recreate every session bound to the old credential revision or let auth.command serve the new profile-bound credential to the same process.

Suggested regression coverage:

• successful CodexChatGptAuth.exchange, followed by another turn on the same child;
• one active turn crossing access-token expiry;
• manual re-auth timeout/cancellation after provider.auth.start;
• credential replacement must not destroy the last usable session until adoption commits.

This overlaps the active-turn case in #17445. I can validate a candidate Beta on this remote Linux setup. Evidence above comes from the server trace, decoded provider protocol log, process start times, and the live launch configuration. Account identity, token values, request IDs, thread IDs, repository details, host address, and raw logs are intentionally omitted.

Confirmed again on macOS with T3 Code 0.1.2-nightly.20261021.3486. This incident directly compares the expired token in the live managed Codex process with the renewed credential in T3's store.

Observed on October 21, 2026, UTC:

• The shared managed Codex app-server had an ACCESS_TOKEN issued at 22:24:59, expiring at 23:24:59.
• At 23:25:44.358, an incoming codex.app-server error reports 401 Unauthorized, auth error code: token_expired, from https://api.openai.com/v1/responses. The turn then fails with willRetry: false.
• At inspection, T3's saved credential was already renewed, expiring at 00:25:34.666 on October 22. The running process still held the earlier, expired token. Comparing the two values in memory confirmed they differed; neither value was printed or included here.
• A direct request using the old process token reproduced the exact 401 token_expired response.
• A direct Responses API request using the renewed stored token returned HTTP 200, generated OK with gpt-6.1-sol, and emitted response.completed.

The inspected process was launched with:

The installed server bundle still resolves the managed runtime when CodexAdapterV2.openSession runs. CodexManagedRuntime supplies ACCESS_TOKEN: credentials.accessToken and returns revision: credentials.accessToken; the retained app-server does not receive the renewed environment value.

This confirms successful credential renewal followed by use of stale launch-time credentials in the existing process on this nightly. It does not require an OAuth refresh failure to explain the observed 401.

For immediate cleanup, we checked that this provider had no running or starting turns and stopped only its idle stale Codex process. The successful inference above verifies the renewed credential directly; recovery through an existing T3 conversation and another full token-expiry interval have not been tested. No permanent installed-code fix is claimed.

Posted by Codex at the user's request. Credential values, account identities, local paths, host addresses, and private conversation IDs are omitted.

Fresh triage on Linux at main b5a226e49c: read the report and all 17 comments, and paged through open issues. No older exact duplicate found; #17445 covers expiry during an active turn.

Runtime reproduction is blocked at step 1: this environment has API-key Codex authentication, without a managed ChatGPT account for the sign-in/renewal sequence. No real-app reproduction or fix verification is claimed. Source inspection still finds launch-time ACCESS_TOKEN in CodexManagedRuntime and runtime resolution at CodexAdapterV2.openSession.

This is an ordinary bug report, not a reported exploitable vulnerability. The fix involves credential delivery/session renewal, which requires maintainer handling under this triage run's sensitive-surface rule. Leaving open; no patch or competing PR created. The blocker is the triage environment, not missing reporter detail.

Additional recurrence and impact report from October 22, 2026, posted by Codex at the user's request.

Frequency and impact

The user reports encountering this expired-authentication failure roughly 10–15 times, possibly more, during approximately 12 hours of work. This is an estimate from recollection, not an exact count. They report needing to fully close and reopen T3 to continue working. The interruption has recurred repeatedly rather than being a one-off sign-in problem.

Current environment

• T3 server version, read through t3_environment_read: 0.1.2-nightly.20261022.3541
• Platform: Windows x64
• Provider/model for the observed delegated tasks: Codex / gpt-6.1-sol

Directly observed in this conversation

At least two distinct delegated coding tasks failed with the following response. One of the earlier failures was delivered twice with the same request ID; those duplicate notifications are not counted as separate underlying failures here.

Distinct request IDs captured:

• req_dc56732a0ee242f19f6922ff701e5d58
• req_bde6893e029645abbb19790faab896a3

The most recent delegated implementation task failed immediately after being launched, preventing the delegated work from proceeding. No token values, private task/conversation identifiers, project content, local paths, or machine/account identifiers are included.

Expected behavior

Credential renewal and recovery should allow ongoing conversations and delegated tasks to continue without manually restarting the application. A newly launched delegated task should not inherit unusable expired authentication.

Verification limits

This update verifies the error responses and current T3 server version, and records the user's approximate frequency and restart workaround. We did not inspect credentials, establish the current refresh/process-invalidation mechanism, or perform a controlled full-expiry reproduction. It does not claim that the underlying cause has been independently reconfirmed on this build.

Related active-run report: #17445.

With the original provider and Sign in with ChatGPT, requests failed about every hour with 401 token_expired. The Codex Windows app worked without this problem.

The provider log contains the exact request ID from my screenshot:

2026-10-21T23:32:46.519Z 401 Unauthorized Provided authentication token is expired. Endpoint: https://api.openai.com/v1/responses Auth error code: token_expired Request ID: req_3febac2c15d94557a29ee71e72a5d463 willRetry: false

The next event marks the turn as failed.

Source review of v0.1.1 is consistent with the running Managed Codex process retaining an expired token. The logs do not prove whether T3 renewed the saved credentials during this incident.

Environment:

• Windows x64, build 10.0.26300.
• Affected T3 version: not confirmed.
• Local T3 server at triage: 0.1.1.
• Triage CLI: 0.1.2, run with npx t3 triage.
• Triage date: October 22, 2026.

Manual mode resolved the problem for me. This is a workaround; it does not confirm that Managed mode is fixed.

Working workaround: add a second Codex provider and select Manual configuration.

This stopped the recurring expired-token errors on my Windows PC. My working setup is:

1. Keep the existing Codex installation signed in.
2. Add a second Codex provider in T3.
3. Select Manual configuration. I have no custom paths saved.
4. Use that provider and disable the original Managed provider.

Settings confirm that the working provider uses setupMode: "existing". The disabled original provider uses setupMode: "managed".

Prepared by Codex (GPT-6) through t3 triage.

@juliusmarminge I see a recurring theme here of Windows users experiencing the issue.

Fixed by #21786 and #21787. The server now owns ChatGPT token renewal, and running Codex sessions fetch fresh tokens through Codex's native auth command, so long runs and conversations no longer hit expired-token 401s or need a restart. This ships in the next release.