Skip to content

Codex managed mode: running sessions keep using an expired 1-hour token #24536

New issue
New issue
Closed
Closed
Codex managed mode: running sessions keep using an expired 1-hour token#24536
Labels
bugSomething is broken or behaving incorrectly.needs-triageIssue needs maintainer review and initial categorization.

Description

@JurassicJoe
JurassicJoe
opened on Oct 24, 2026

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

  1. In T3 Code, use a Codex provider instance in "managed" mode (provider instance codex, model gpt-6.1-sol).
  2. Start a Codex thread using a Codex app-server process that is already running.
  3. Wait until the 1-hour token that process was started with expires. T3 exchanges the ChatGPT login for a short-lived token roughly every hour, but it does not pass the renewed token to the already-running process.
  4. Run another Codex thread using that process.

Observed behaviour (Algo-Node PC, Oct 24, 2026):

  • Every thread using provider instance codex (model gpt-6.1-sol) failed about 14 seconds after launch, with no model output, consistent with a 401 from the provider. Claude (Opus) threads worked fine.
  • T3 exchanges the ChatGPT login for a short-lived token roughly every hour. Log exchanges seen at 13:50, 14:50, 16:00, and 18:15 UTC.
  • The Codex process sessions used (pid 19968) started at 16:58 UTC holding the token from the 16:00 exchange, which expired at 17:00. Every Sol thread after that hit a dead token.
  • The on-disk Codex login (~/.codex/auth.json) was valid until Nov 3, and the Codex desktop app on the same PC logged zero token_expired errors. Managed mode does not read that file.
  • Reconnecting the Codex provider starts a new process with a fresh token, so it works for up to an hour, then fails again the same way. The same pattern occurred earlier with another process around 05:45 UTC.
  • This is not a cross-device conflict. No refresh_token_reused or token_invalidated errors were seen (which would indicate a Mac login revoking the PC token). The error is always token_expired — an old token sent, not a revoked one. The Mac works because its Codex session process is younger, or it is not using managed mode.

Expected behavior

When T3 renews the managed Codex token, running Codex sessions should either:

  1. Receive the renewed token without user action, or
  2. Be restarted automatically with the new token, with the thread resuming, or
  3. Fail with a clear "token expired, restarting session" recovery, not a silent 14-second launch failure.

Actual behavior

In T3 Code, a Codex provider instance in "managed" mode trades the user's ChatGPT login for an access token that lasts exactly 1 hour. T3 does get a new token roughly every hour, but it does not pass the renewed token to a Codex app-server process that is already running. That process keeps the token it was started with, so every Codex thread using that process fails with 401 token_expired once that token expires, until the user reconnects the provider or the process is restarted.

Mechanism found by diagnostics:

  • T3's Codex process relies on a static ACCESS_TOKEN environment variable via an openai_token_sharing provider with requires_openai_auth=false, so Codex never refreshes the token itself.
  • Managed mode therefore depends entirely on T3 to restart or re-token running sessions when it renews — and it does not.

Impact

Blocks work completely

Version or commit

T3 Code (Beta) server v0.1.2

Environment

T3 Code (Beta) server v0.1.2, Algo-Node PC (Windows), Codex 0.156.1 (T3-managed binary path C:\Users\joesl\.t3\tools\codex\0.156.1\bin\codex.exe) Provider instance: codex, driver codex, model gpt-6.1-sol Settings file: C:\Users\joesl\.t3\userdata\settings.json, providerInstances.codex.config.setupMode = "managed" (default, before workaround attempts) No secrets are included in this report. Token values, auth codes, and account identifiers have been omitted.

Logs or stack traces

`401 token_expired` — an old token sent, not a revoked one. No `refresh_token_reused` or `token_invalidated` errors were seen.

Screenshots, recordings, or supporting files

No response

Workaround

  • Reconnect the Codex provider in T3 settings — lasts up to 1 hour.
  • End the stale Codex process so T3 starts a new one with a fresh token.
  • Switch the instance to "existing" mode (providerInstances.codex.config.setupMode = "existing", with homePath = ~/.codex and the T3-managed binaryPath) so Codex uses its own refreshable login. Note: on the PC this changed the available model list — gpt-6.1-sol was no longer listed, only gpt-6-astra and gpt-6-luna — so existing mode is not a drop-in replacement if the user needs gpt-6.1-sol.
  • Use a different machine / instance where Codex is not in managed mode.

Proposed fix (for a PR):

  • On managed token renewal, restart the Codex app-server process (or re-inject the new ACCESS_TOKEN) for sessions using that instance, before they next run, instead of leaving them on the expired token.
  • Alternatively, do not set requires_openai_auth=false with a static env token for long-lived sessions, or pass the token through a refreshable channel.
  • At minimum, surface the token expiry in the thread UI ("Codex token expired at HH:MM, restarting session") instead of a bare launch failure with no output.

Activity

  1. JurassicJoe
    added
    bugSomething is broken or behaving incorrectly.
    needs-triageIssue needs maintainer review and initial categorization.
    on Oct 24, 2026

  2. dfhasdh commented on Oct 25, 2026

    @dfhasdh
    dfhasdh
    on Oct 25, 2026

    Additional independent reproduction on Linux, with process and installed-code evidence. This also resembles the previously closed #16132 and #17445.

    Environment: T3 0.0.46-nightly.20261014.3132, managed Codex CLI 0.164.0, CachyOS/Arch Linux, a separate managed ChatGPT Personal provider instance.

    Observed sequence (October 24–25, 2026; America/Chicago, UTC−05:00):

    • The affected app-server inherited an access token issued at 16:12:08, expiring at 17:12:08. Only the JWT timestamps were inspected; no token values are included here.
    • T3 logged a successful CodexChatGptAuth.exchange at 17:11:26.798–17:11:28.056; the encrypted credential file changed at 17:11:27.553.
    • The next request failed at 17:12:31.011, shortly after the worker's original token expired, then retried five times before failing at 17:12:40.415. Another request failed at 17:24:00.663.
    • The same stale worker remained running while successful credential exchanges continued hourly through 21:12:44; requests still returned token_expired around 22:01.
    • After a later T3 restart, the affected provider produced a successful reply at 23:52. A further successful refresh was logged around 00:12, followed by the same expired-token failure at 00:19:41.240 on October 25 and another sequence of five retries ending at 00:20:19.557. Restarting therefore provided temporary recovery only.

    Representative error, with request/account identifiers omitted:

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

    Installed-code inspection: These findings are from JavaScript sections extracted read-only from the installed executable, not a checkout of current main:

    • CodexManagedRuntime.ts obtains auth.access, returns environment.ACCESS_TOKEN = credentials.accessToken, and also returns revision: credentials.accessToken.
    • Managed launch arguments select openai_token_sharing, env_key="ACCESS_TOKEN", and requires_openai_auth=false.
    • CodexAdapterV2 resolves the managed runtime in openSession and opens the client using that environment. In the inspected adapter, startTurn reuses the existing client; there is no further runtime resolution or consumption of the runtime revision.
    • Credential renewal/storage exists in CodexChatGptAuth; the observed refresh exchanges succeeded. This is distinct from a refresh request failing with invalid_grant.

    This supports a lifecycle gap between saved credential rotation and the already-running worker's inherited environment. A repair should coordinate replacement of the managed app-server with fresh credentials, preserve/resume native threads, and account for active turns, including expiration during a long run. Repeating requests against the same expired worker does not recover it.

    One recovery caveat from this reproduction: stopping only the confirmed idle stale app-server did not recover the provider. T3 retained a ready session handle, and the next verification failed with Codex App Server process exited with code 0. A full T3 restart subsequently restored a reply temporarily.

    No installed code or credentials were edited during the investigation. No patched build or post-fix longevity test has been run, and this report does not establish whether current main already fixes the issue.

  3. pranshu-shah-at-quicko commented on Oct 27, 2026

    @pranshu-shah-at-quicko
    pranshu-shah-at-quicko
    on Oct 27, 2026 – with ChatGPT Codex Connector

    Possible additional reproduction involving a Codex subagent delegated from a Claude parent thread.

    Environment

    • Windows x64.
    • Current T3 Code server version: 0.1.2. The version at the time of failure has not been independently verified.
    • Parent provider: claudeAgent, model claude-opus-5-5.
    • Subagent provider: codex, model gpt-6.1-sol.
    • Subagent runtime mode: full-access.
    • Codex setup mode and CLI version have not been verified.

    Observed sequence

    All timestamps are UTC on October 27, 2026.

    1. At 19:23:14, T3 started a delegated Codex review task.
    2. The subagent generated a response and executed read-only commands.
    3. At 19:24:42, a subsequent provider request failed with 401 token_expired.
    4. T3 marked the delegated task as failed. The subagent did not deliver its review.

    The relevant error was:

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

    Provider request ID: req_6ac6ddcdc5c544b38d413ce9debb2cd2.

    Expected behavior

    An expired credential should not permanently terminate a delegated task without a recovery path. T3 should either recover authentication and allow the task to continue, or provide an actionable reauthentication flow.

    Impact and subsequent check

    The delegated review failed, while the Claude parent remained usable.

    A later authentication smoke test created a fresh subagent with the same provider and model. That task completed successfully. No authentication changes were made as part of that test.

    Investigation limits

    I do not have a deterministic reproduction. I have not inspected credential refresh logs, token expiry timestamps, or the affected worker's environment.

    This case confirms a mid-task token_expired failure. It does not establish whether the cause is the stale managed token described in this issue. The later successful test also does not establish that the underlying problem is fixed.

  4. t3dotgg commented on Nov 1, 2026

    @t3dotgg
    t3dotgg
    on Nov 1, 2026
    Member

    Note

    🤖 GPT-6.1 Terra [1m] responding on behalf of Theo

    Closing as fixed by the managed Codex token helper. The runtime obtains a renewed token for the running process, and its regression test verifies renewal after expiry without restarting the session. #21787 #21786

  5. t3dotgg
    closed this as completedon Nov 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is broken or behaving incorrectly.needs-triageIssue needs maintainer review and initial categorization.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions