Codex Desktop and CLI sharing CODEX_HOME causes local provider state and CLI threads to leak into Desktop

Summary

On Windows, Codex Desktop and Codex CLI appear to share the same default CODEX_HOME (%USERPROFILE%\.codex).

After configuring Codex CLI to use a local llama.cpp OpenAI-compatible provider, CLI-created threads appeared in the Codex Desktop Recent sidebar. During the same incident, Codex Desktop also temporarily entered an abnormal authentication/provider state and returned HTTP 403 errors.

After rebuilding part of the Codex Desktop/Codex shared state, the Desktop ChatGPT subscription state recovered and the 403 errors disappeared. However, the CLI-created threads remained visible in Desktop Recent.

Initially, using Archive on those CLI threads had no effect.

After the Desktop state had been rebuilt and the application restarted several times during troubleshooting, using Archive again successfully removed the CLI threads from Recent. Interestingly, those threads did not subsequently appear in the Desktop Archived Threads view.

This suggests that Desktop/CLI sharing of CODEX_HOME can produce inconsistent thread/provider/session state, particularly when the CLI is configured with a custom local model provider.

---

Environment

• OS: Windows
• Codex Desktop: Microsoft Store version
• Codex CLI: 0.147.0
• Default shared Codex home:

C:\Users\<username>\.codex

• Local inference server: llama.cpp / llama-server
• OpenAI-compatible endpoint:

http://127.0.0.1:8003/v1

• Local model:

Qwen3.5-14B-A3B-Coder

• Codex Desktop normally authenticated using a ChatGPT subscription.
• Codex Desktop model after recovery:

gpt-5.6-sol

The Microsoft Store package was:

OpenAI.Codex_2p2nqsd0c76g0

---

What I Was Trying to Do

I wanted to use:

Codex Desktop
→ ChatGPT subscription
→ OpenAI models

while separately using:

Codex CLI
→ local llama.cpp server
→ local Qwen model

The intention was for the local model to be used only by Codex CLI.

However, Codex CLI initially used the same default:

%USERPROFILE%\.codex

directory as Codex Desktop.

---

Local Provider Configuration

The local llama-server was successfully running at:

http://127.0.0.1:8003/v1

The server reported the model as:

Qwen3.5-14B-A3B-Coder

The OpenAI-compatible Responses endpoint worked correctly.

For example, a test request returned:

status       : completed
model        : Qwen3.5-14B-A3B-Coder
input_tokens : 13
output_tokens: 39
total_tokens : 52

So the local llama.cpp endpoint itself was functioning.

---

Codex CLI Behavior

Codex CLI successfully recognized the local provider:

Model:          Qwen3.5-14B-A3B-Coder
Model provider: Local llama.cpp - http://127.0.0.1:8003/v1
Directory:      D:\OpenCodeTest
Context window: 32.8K

During testing, several very small CLI threads were created, including:

hello
what is model
local
quit

---

Unexpected Desktop Behavior

After using Codex CLI with the local provider, those CLI-created threads appeared in the Codex Desktop Recent sidebar.

For example:

Recent

hello
what is model
local
quit

A thread could also show information such as:

OpenCodeTest
Work
Run on your computer

These were definitely threads created during the Codex CLI/local-model testing rather than normal Codex Desktop conversations.

---

More Serious Problem: Desktop Authentication / Provider State

During the incident, Codex Desktop also temporarily entered an abnormal state.

Requests returned HTTP 403 errors and the normal subscription/model behavior was disrupted.

The existing Desktop config.toml was eventually restored to a normal OpenAI configuration:

model = "gpt-5.6-sol"
model_reasoning_effort = "medium"

There was no remaining local llama.cpp provider in this restored Desktop configuration.

The following files remained intact:

auth.json
config.toml

auth.json was deliberately not deleted.

---

State Recovery

Before modifying anything further, the entire .codex directory was backed up.

Several state files were then renamed rather than deleted so that all changes remained reversible.

An important recovery step involved rebuilding state associated with files such as:

.codex-global-state.json
session_index.jsonl
thread_history_1.sqlite

After restarting Codex Desktop:

ChatGPT subscription state recovered
gpt-5.6-sol became available normally
HTTP 403 disappeared
official model list returned

This was the clearest point at which the core Desktop state returned to normal.

However, the CLI-created threads were still visible under Desktop Recent.

---

Investigation of the Remaining CLI Threads

The following storage locations were investigated.

Shared Codex state

%USERPROFILE%\.codex\

Files included:

.codex-global-state.json
history.jsonl
session_index.jsonl
thread_history_1.sqlite
state_5.sqlite
logs_2.sqlite
goals_1.sqlite
memories_1.sqlite
queue_1.sqlite

Various history/state files were backed up and temporarily renamed.

The CLI threads remained visible in Desktop Recent.

---

Session Rollout Files

Codex also contained:

%USERPROFILE%\.codex\sessions\

The dates and timestamps of several rollout files matched the CLI/local-model testing sessions, for example:

sessions\2026\08\17\
    rollout-2026-08-17T22-51-56-....jsonl
    rollout-2026-08-17T22-55-46-....jsonl
    rollout-2026-08-17T22-57-54-....jsonl
    rollout-2026-08-17T23-00-42-....jsonl

There was also:

%USERPROFILE%\.codex\archived_sessions\

Temporarily isolating the relevant rollout/session data did not immediately remove the CLI threads from the Desktop Recent sidebar.

---

Codex Desktop Microsoft Store Storage

The Desktop application also maintained its own application data under:

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\

The Chromium/WebView profile contained data such as:

LocalCache\Roaming\Codex\web\Codex\Default\

including:

Local Storage\leveldb

and another application partition containing its own LevelDB storage.

Temporarily isolating the normal WebView Local Storage also did not immediately remove the CLI threads from Recent.

Therefore, I cannot conclude that a specific SQLite, JSONL, rollout, or LevelDB file alone was responsible for the stale Recent entries.

---

Archive Behavior

This was the most unusual part of the problem.

Before Desktop state recovery

Using Archive on the CLI-created Recent threads appeared to do nothing.

The threads remained visible.

After Desktop state recovery

After restoring the normal Desktop authentication/model state and performing the state rebuild/restarts described above, I tried Archive again.

This time:

hello
what is model
local
quit

disappeared from the Desktop Recent sidebar.

However, when opening the Desktop Archived Threads view, those CLI-created threads were not present there either.

The final result was therefore:

Desktop Recent:
CLI threads removed

Desktop Archived:
CLI threads not present

Normal Desktop conversations:
preserved

ChatGPT subscription:
working

gpt-5.6-sol:
working

HTTP 403:
gone

---

Important Observation

The successful second Archive operation did not behave like a normal:

Recent → Archived

transition.

It behaved more like:

stale/orphan CLI thread reference
        ↓
Archive
        ↓
removed from Recent index
        ↓
no corresponding Desktop Archived thread

This may indicate that the Desktop sidebar knew about the CLI thread but did not have a completely consistent Desktop thread representation for it.

---

What Is Confirmed

The following observations were reproduced directly during troubleshooting:

1. Codex Desktop and Codex CLI were using the same default %USERPROFILE%\.codex directory.

1. Threads created while testing the local model through Codex CLI appeared in Codex Desktop Recent.

1. Codex Desktop temporarily experienced an abnormal authentication/provider state and HTTP 403 errors during the incident.

1. Rebuilding shared/Desktop state restored normal ChatGPT subscription behavior and eliminated the 403 errors.

1. The CLI threads remained in Desktop Recent after the core Desktop state recovered.

1. Renaming several individual history/database/session files did not immediately remove the Recent entries.

1. Archive initially appeared ineffective.

1. After Desktop state recovery/restarts, Archive successfully removed the CLI threads.

1. The removed CLI threads did not appear in the Desktop Archived Threads view.

---

What Is NOT Confirmed

I cannot determine which individual file or database caused the issue.

In particular, I cannot prove that the root cause was specifically:

.codex-global-state.json
session_index.jsonl
thread_history_1.sqlite
state_5.sqlite
logs_2.sqlite
sessions/*.jsonl
WebView LevelDB

Several variables changed during troubleshooting, so attributing the recovery to one particular file would not be reliable.

The strongest observed correlation is that rebuilding the core Codex/Desktop state and restarting Desktop restored authentication/provider behavior, after which Archive eventually became capable of removing the stale CLI threads.

---

Expected Behavior

Ideally, Codex Desktop and Codex CLI should not unintentionally contaminate each other's provider/authentication/thread state when the CLI uses a custom local provider.

Possible expected behaviors:

1. Desktop and CLI could maintain separate provider configuration/state by default.

1. CLI threads created with a custom provider could be marked as CLI/local threads.

1. Desktop could decide whether to display CLI-created threads.

1. A local CLI provider should not affect the Desktop ChatGPT subscription authentication/provider state.

1. Archive should behave consistently.

1. If a CLI thread is shown in Desktop and archived, it should either:

• appear normally under Archived Threads, or
• be clearly identified as a local/CLI-only thread that is being removed from Desktop history.

---

Suggested Product Improvements

1. Separate Desktop and CLI state

Consider separating:

Codex Desktop state

from:

Codex CLI state

especially:

provider
authentication
thread index
session metadata

when a custom provider is configured.

2. Warn when changing provider in a shared CODEX_HOME

If CLI detects that its CODEX_HOME is also being used by Codex Desktop, changing to a custom provider could display a warning such as:

This CODEX_HOME is shared with Codex Desktop. Custom provider configuration or CLI sessions may affect Desktop state.

3. Identify thread origin

Thread metadata could include an explicit origin:

Desktop
CLI
CLI - Custom Provider

This would make mixed histories much easier to understand.

4. Improve Archive handling for stale threads

If Desktop detects a thread that exists in Recent but cannot be represented as a normal archived Desktop thread, it could explicitly offer:

Remove from Recent

rather than presenting Archive and apparently doing nothing.

5. Provide an official local-provider isolation workflow

Documentation could recommend:

$env:CODEX_HOME="D:\codex-local"
codex

when using Codex CLI with a local or third-party OpenAI-compatible provider.

---

Workaround

The safest long-term workaround is to give Codex CLI a separate CODEX_HOME.

For example:

$env:CODEX_HOME="D:\codex-local"
codex

This creates the intended separation:

Codex Desktop
│
├─ %USERPROFILE%\.codex
├─ ChatGPT subscription
├─ OpenAI models
└─ Desktop history


Codex CLI
│
├─ D:\codex-local
├─ llama.cpp
├─ Qwen3.5-14B-A3B-Coder
└─ CLI/local history

This should prevent future local CLI testing from sharing the same configuration/session store with Codex Desktop.

---

Safety Note for Other Users Experiencing This

I strongly recommend not immediately deleting the entire .codex directory.

Before troubleshooting:

Copy-Item "$HOME\.codex" "$HOME\.codex_backup" -Recurse

Prefer renaming suspected state files to .old rather than deleting them.

In particular, avoid deleting:

auth.json
config.toml

unless there is a specific reason to reset authentication/configuration.

The important lesson from this incident is that a thread remaining visible in the Desktop sidebar does not necessarily mean that its corresponding JSONL/SQLite/session file is still the authoritative source for that UI entry.

The Desktop UI, shared Codex state, session data, and thread indexes can apparently become temporarily inconsistent after Desktop and CLI share state while using different providers.