[Bug]: Managed Codex sign-in leaves a remembered account with no visible existing-CLI recovery #17461

Before submitting

• I searched existing issues and did not find an exact duplicate.
• I included the observed state, investigation evidence, verified workaround, and reproduction limits.

Area

apps/desktop

Observed in desktop Settings → Providers; the relevant state also involves the managed Codex provider and web settings UI.

Steps to reproduce

I encountered this in a specific existing installation. I have not established a deterministic way to recreate the original sign-in failure from a clean setup.

The affected state was:

1. The Codex provider was configured with setupMode: "managed".
2. T3 had a saved ChatGPT account registration, but the corresponding managed credential record was absent.
3. Settings → Providers showed the remembered account with Reconnect account and Use a different account, while the provider reported Not authenticated · Sign in with ChatGPT to use Codex. and zero models.
4. The desktop logs recorded two failed ChatGPT callback attempts.
5. On the same macOS user account, codex login status reported Logged in using ChatGPT. T3 resolved the expected CLI version and the same user-local Codex home.
6. After backing up T3's settings, changing only providerInstances.codex.config.setupMode from "managed" to "existing" immediately restored authenticated status and model discovery through the settings watcher.

This documents the observed failure state and recovery. It does not establish why the original callbacks failed.

Expected behavior

Please make the recovery path clear when a remembered managed account has no usable session. The account display should explain that another managed sign-in is needed and make the documented existing-CLI workflow discoverable from this state.

I understand that managed ChatGPT connections and CLI authentication are separate. My concern is the recovery experience after managed sign-in fails; I would appreciate clarification if an existing UI path was missed.

Actual behavior

The remembered-account controls and generic sign-in message left it unclear why a CLI that was already logged in could not be used. Use existing CLI was not visible in the inspected provider settings state.

This is easy to mistake for a routine missing login or an incorrect home directory. The important detail is that the managed registration was present, the managed token was absent, and the working CLI login was separate. Switching the mode alone restored Authenticated · ChatGPT Plus Subscription and seven models, without restarting T3 or signing in again.

Impact

Minor bug or occasional failure.

Codex was unavailable through this provider until the settings-file workaround was found. Other providers remained available. The missing visible recovery path made the incident difficult to diagnose.

Version or commit

0.0.46-nightly.20261007.2761

The newer October 9 nightly has not been tested for this failure state.

Environment

macOS 27.0, Apple Silicon (arm64), T3 Code Nightly desktop app connected to its local server; Codex CLI 0.162.0, installed through Homebrew.

The Mac has two separate macOS user accounts, one for work and one for personal use. T3 is used on both for different purposes, with the same personal ChatGPT subscription used for Codex. This may be useful context for investigating callback routing, but the inspection confirmed the correct work-user Codex home. Cross-user credential mixing or a causal role for the second macOS account has not been established.

Logs or stack traces

Two desktop callback attempts recorded:

CodexAuthCallbackError: Could not receive ChatGPT sign-in on this computer. Try again or paste the redirect URL.
    at desktop.ipc.providerAuth.receive

Selected diagnostic results:

Codex CLI:
  codex-cli 0.162.0
  Logged in using ChatGPT

T3 before recovery:
  setupMode: managed
  installed: true
  version: 0.162.0
  auth.status: unauthenticated
  models: []
  managed account registration: present
  corresponding managed credential record: absent

T3 after changing only setupMode to existing:
  Authenticated · ChatGPT Plus Subscription
  7 models

Inspection of the installed server bundle showed that CodexManagedProvider reads T3-owned ChatGPT credentials separately from the CLI's credentials. That explains the status in this state, but not the callback failure.

Screenshots, recordings, or supporting files

The investigation captured the before/after UI through accessibility observations and checked the local provider configuration, cache, credential-record presence, and relevant trace entries. No screenshots are attached. Account identifiers, credentials, and absolute home paths have been omitted.

Related reports checked:

• #14321: different model catalogs between managed and CLI logins; this report concerns a missing managed session and recovery.
• #16106: CLI probes timing out through mise shims; here T3 detected the CLI and version, and a mode change alone restored authentication.
• #16132: conversations failing after managed-token renewal; no renewed managed session was present in this incident.

Workaround

Back up ~/.t3/userdata/settings.json, then change:

providerInstances.codex.config.setupMode:
  "managed" → "existing"

T3 applied the change automatically and displayed authenticated status and models immediately. No new inference request was run, so the verification covers authentication and model discovery.

Thank you for taking a look. I am sharing this because the combination of a remembered account and a working CLI login makes the failed managed-sign-in state unusually easy to overlook. The appropriate fix may be guidance or a clearer recovery control; I am leaving that choice to the maintainers.

Prepared by Codex from the local investigation at the user's request. This was not run through npx t3 triage.