Codex "Reset to default" removes setupMode, and the settings card offers no way back to managed setup#28885

opened3d agobyBblakedh

What happened

After first launch I added Claude and Codex as providers. In Settings I accidentally clicked "Reset to default" on the Codex provider. It cleared all Codex provider settings, which broke the Codex integration, and there was no obvious way to restore them. I got Codex working again by setting "Binary path" to the managed binary under ~/.t3/tools/codex/, but I couldn't tell whether other settings from the initial setup were still missing.

Diagnosis

The reset button on the default Codex instance (ProviderSettingsPanel.tsx, resetDefaultInstance) calls persistProviderInstance({ operation: "remove" }), which deletes the whole providerInstances.codex entry instead of restoring the config that onboarding wrote.

Onboarding and AddCodexAccountDialog save managed Codex as { enabled: true, setupMode: "managed" } (WelcomeWizard.tsx:897, AddCodexAccountDialog.tsx:67). setupMode is a hidden form field (packages/contracts/src/settings.ts:631). Once the entry is removed, readCodexSetupMode returns "existing", and the settings card renders CodexSetupSection, the only place with the managed/existing mode switch, only when the mode is "managed" (ProviderSettingsPanel.tsx:1327). So after a reset, nothing in Settings can switch the instance back to managed.

The obvious workaround makes things worse: setting "Binary path" to the managed binary runs Codex as an existing CLI. That uses ~/.codex instead of T3's managed home and login (CodexManagedRuntime.ts), pins the path to one Codex version folder, and makes managed install and update refuse with "This instance uses a custom executable" (providerInstallation.ts:88).

The reset may also delete the instance's stored managed ChatGPT credentials, so the user has to sign in again after restoring managed mode.

resetDefaultInstance is unchanged on main as of 2026-11-01.

Possible fixes: reset the default Codex instance to its onboarding config (keep setupMode), confirm before resetting, and/or show the managed/existing mode switch in the settings card whatever the current mode.

Because isDirty is true whenever an explicit instance exists, the reset button shows for every managed Codex install straight after onboarding.

Steps to reproduce

Fresh install of the desktop app (0.1.6). In onboarding, set up Codex with managed setup.
Open Settings → Providers → Codex. The "Reset to default" button already shows in the card header, because the onboarding config counts as a change (isDirty = explicitInstance !== undefined, ProviderSettingsPanel.tsx:734).
Click it.
Observe: providerInstances.codex is gone from settings.json, the Codex card no longer shows managed setup, and nothing in Settings switches it back to managed. Codex no longer works unless a working codex is on PATH.

Version

0.1.6 (T3 Code (Beta) desktop app; the local server also reports 0.1.6)

Environment

macOS 27.2 (darwin arm64), Node v24.22.1, managed Codex 0.156.1, no codex on PATH

Evidence

shell

1	# settings.json after the reset, plus the user's binaryPath workaround (setupMode missing):
2	"providerInstances": { "codex": { "driver": "codex", "config": { "binaryPath": "~/.t3/tools/codex/0.156.1/bin/codex" } } }
3
4	# ~/.t3/tools/codex/active.json (managed install from onboarding is still present)
5	{"version":"0.156.1"}
6
7	# The server trace has no settings-change events, so the reset itself is not logged.

Searched for reset/Codex/managed/provider settings and found no match. #19025 (setting changes don't reach live sessions) and #21249 (managed installs can update past their pin) are about different problems.

Fix applied or workaround

Backed up settings.json and replaced the Codex entry with { "driver": "codex", "config": { "enabled": true, "setupMode": "managed" } }, removing the custom binaryPath. The server reloaded the file live and went back to the managed Codex runtime.

Filed by

Claude Code (claude-opus-5-5) via t3 triage