codex - 💡(How to fix) Fix Codex Desktop hides local history for custom Azure model provider after restart (e.g. corporate API key) [4 comments, 3 participants]

Local testing showed:

- `thread/list` with `modelProviders: []` returned both `openai` and `azure` threads.
- `thread/list` with `modelProviders: null` could behave like a current-provider filter.
- The Desktop UI bundle contains `thread/list` calls with `modelProviders:null`.

This suggests the Desktop UI may be listing recent threads using provider filter semantics that exclude custom providers after restart, or it may be applying a UI-side provider filter that does not include custom providers.

## Additional Observations

`thread/list` without a `cwd` filter and with `modelProviders: []` returned mixed providers, including both:

---

`thread/list` with a `cwd` filter for Hercules and `modelProviders: []` also returned both `openai` and `azure` threads in that repo.

This further supports that the underlying app-server can return the data needed by the UI.

## Failed Workarounds

### 1. Duplicating Provider Definition Into Repo Config

Duplicating `[model_providers.azure]` into the repo-local `.codex/config.toml` did not fix Desktop history.

CLI still worked and reported:

---

But the Desktop GUI still did not show corporate/Azure chats after restart.

### 2. Trying To Override Built-In `openai` Provider

Attempting to configure built-in `openai` to point at Azure did not work. Codex still sent requests to:

---

This is not a viable workaround.

### 3. Patching `app.asar`

Two local experiments were attempted only to test the provider-filter hypothesis. Both are not viable and should not be used as a workaround.

First attempt:

- Extracted `app.asar`.
- Replaced `modelProviders:null` in JS.
- Repacked `app.asar`.
- Result: Codex Desktop crashed at startup with `EXC_BREAKPOINT (SIGTRAP)`.
- Likely cause: repacking lost original `app.asar.unpacked` metadata for native modules.

Second attempt:

- Performed an in-place byte-preserving edit:

---

to:

---

- Same byte length.
- No extract/repack.
- Updated affected asar integrity hashes in the header.
- Tested successfully on a `/tmp` copy with `@electron/asar list`.
- Result on the real installed app: Codex Desktop still crashed at startup with `EXC_BREAKPOINT (SIGTRAP)`.
- Likely cause: the installed app cannot tolerate mutation of `Resources/app.asar`, probably due to macOS/Electron code signing or resource seal validation.

Relevant crash reports:

---

`Resources/app.asar` is listed in:

---

So mutating the installed app bundle is not a practical workaround.

## Impact

This makes corporate/custom-provider usage unsafe and confusing:

- Work is not lost, but appears lost in the GUI.
- Users cannot reliably reopen or continue corporate Azure chats from Desktop history.
- Personal/default OpenAI history works, making the issue look provider-specific.
- The intended setup of “corporate provider for one repo, personal provider elsewhere” becomes hard to use in Desktop.
- Users may incorrectly assume their corporate chat history was deleted.

## Requested Fix

Please make Codex Desktop recent/history views include custom provider threads correctly.

Specifically:

1. Ensure `thread/list` calls intended to include all local threads use the correct provider filter semantics.
2. Treat `modelProviders: []` as “all providers” consistently, per the generated app-server protocol.
3. Ensure custom providers such as `azure` are visible in recent chat history after app restart.
4. Ensure opening/resuming a custom-provider thread renders existing turns instead of a blank UI.
5. Add regression coverage for local custom providers with:
   - `source = "vscode"`
   - `model_provider != "openai"`
   - repo-scoped config selecting a custom provider
   - persisted local rollout JSONL history

## Security Notes

- No API key is included in this report.
- The Azure endpoint is redacted.
- Corporate chat content examples are limited to short thread titles/previews.

### What steps can reproduce the bug?

## Reproduction

1. Configure a custom model provider named `azure` in `~/.codex/config.toml`.
2. Configure one repo with local `.codex/config.toml` selecting:

---

3. Open Codex Desktop in that repo.
4. Start one or more chats and verify that turns complete successfully through the Azure provider.
5. Restart Codex Desktop.
6. Check recent chat history.
7. Observe that Azure-provider chats are missing or fail to open correctly, while default `openai` chats remain visible.


### What is the expected behavior?

## Expected Behavior

1. Threads created in the Hercules repo with `model_provider = "azure"` should appear in Codex Desktop recent chat history.
2. After restarting Codex Desktop, those Azure threads should still appear.
3. Opening an Azure thread should render the existing conversation turns, same as `model_provider = "openai"` threads.
4. Personal/default OpenAI threads from other repositories should continue to appear and open normally.

## Actual Behavior

1. Azure/provider-specific chats are created and saved successfully.
2. They may appear temporarily in the Desktop GUI.
3. After restarting Codex Desktop, Azure chats disappear from GUI history or open to a blank screen.
4. Non-Azure/default OpenAI chats still appear and open normally.
5. The missing Azure chats are not deleted and are not archived.


### Additional information

---

These rows are present in:

---

Their rollout JSONL files also exist under:

---

## Evidence: Local App-Server Can Read The Threads

Using the local Codex app-server WebSocket API, both `thread/list` and `thread/read` can see/read the Azure threads.

Example `thread/read` for:

---

Returned:

---

This indicates that the backend/state layer can load the conversation and the data is not lost.

## Evidence: Provider Filter Semantics May Be Involved

Generated app-server TypeScript protocol says:

---

Local testing showed:

- `thread/list` with `modelProviders: []` returned both `openai` and `azure` threads.
- `thread/list` with `modelProviders: null` could behave like a current-provider filter.
- The Desktop UI bundle contains `thread/list` calls with `modelProviders:null`.

This suggests the Desktop UI may be listing recent threads using provider filter semantics that exclude custom providers after restart, or it may be applying a UI-side provider filter that does not include custom providers.

## Additional Observations

`thread/list` without a `cwd` filter and with `modelProviders: []` returned mixed providers, including both:

---

`thread/list` with a `cwd` filter for Hercules and `modelProviders: []` also returned both `openai` and `azure` threads in that repo.

This further supports that the underlying app-server can return the data needed by the UI.

## Failed Workarounds

### 1. Duplicating Provider Definition Into Repo Config

Duplicating `[model_providers.azure]` into the repo-local `.codex/config.toml` did not fix Desktop history.

CLI still worked and reported:

---

But the Desktop GUI still did not show corporate/Azure chats after restart.

### 2. Trying To Override Built-In `openai` Provider

Attempting to configure built-in `openai` to point at Azure did not work. Codex still sent requests to:

---

This is not a viable workaround.

### 3. Patching `app.asar`

Two local experiments were attempted only to test the provider-filter hypothesis. Both are not viable and should not be used as a workaround.

First attempt:

- Extracted `app.asar`.
- Replaced `modelProviders:null` in JS.
- Repacked `app.asar`.
- Result: Codex Desktop crashed at startup with `EXC_BREAKPOINT (SIGTRAP)`.
- Likely cause: repacking lost original `app.asar.unpacked` metadata for native modules.

Second attempt:

- Performed an in-place byte-preserving edit:

---

to:

---

- Same byte length.
- No extract/repack.
- Updated affected asar integrity hashes in the header.
- Tested successfully on a `/tmp` copy with `@electron/asar list`.
- Result on the real installed app: Codex Desktop still crashed at startup with `EXC_BREAKPOINT (SIGTRAP)`.
- Likely cause: the installed app cannot tolerate mutation of `Resources/app.asar`, probably due to macOS/Electron code signing or resource seal validation.

Relevant crash reports:

---

`Resources/app.asar` is listed in: