Desktop app stuck in cloud-only mode; local sessions ignored even with `codexCloudAccess=disabled`

Are you able to create new local sessions from within the app?

I can but they do not persist within the app if it reloads. I can see those sessions in the cli/cursor app etc but the desktop app resets back to cloud only sessions on every reload.

Hmm, very strange. By any chance, are you using CODEX_HOME to define a custom location for your codex directory? I presume not based on your post above, but just want to confirm.

Indeed. no CODEX_HOME, just the default ~/.codex

We're trying to find a repro case for this, and we have some working theories. By any chance, do you have a custom model provider defined in your config.toml? Do you have any other non-default config.toml settings?

@human-bee, I deleted your post because it included some details that you probably don't want publicly shared. Make sure to redact details like access tokens when posting to github.

hah thanks. sorry. i had already cycled them, i do often because of how often .env.local is read. but i appreciate it.

<img width="246" height="921" alt="Image" src="https://github.com/user-attachments/assets/f09d732c-b170-4c63-8f47-d7d1ee12bc82" />

config:

model = "gpt-5.2-codex"
model_reasoning_effort = "high"
approval_policy = "never"
sandbox_workspace_write.network_access = true
sandbox_mode = "danger-full-access"
tool_output_token_limit = 45000
web_search = "live" 
personality = "pragmatic"

[features]
rmcp_client = true
unified_exec = true
shell_snapshot = true
collab = true
steer = true

[profiles.deep-review]
model = "gpt-5-pro"
model_reasoning_effort = "high"
approval_policy = "never"

[projects."/Users/bsteinher/Cursor Tools"]
trust_level = "trusted"

[projects."/Users/bsteinher/PRESENT"]
trust_level = "trusted"

[mcp_servers.chrome-devtools]
command = "npx"
args = ["chrome-devtools-mcp@latest"]
enabled = true

[mcp_servers.supabase]
command = "npx"
args = ["-y", "@supabase/mcp-server-supabase@latest", "--project-ref=<REDACTED>"]

[mcp_servers.supabase.env]
SUPABASE_ACCESS_TOKEN = "<REDACTED>"

[mcp_servers.apify]
url = "https://mcp.apify.com"
enabled = false

[mcp_servers.sentry]
url = "https://mcp.sentry.dev/mcp"
enabled = false

[mcp_servers.github]
command = "npx"
args = ["-y", "@modelcontextprotocol/server-github"]

[mcp_servers.github.env]
GITHUB_PERSONAL_ACCESS_TOKEN = "<REDACTED>"

[mcp_servers.codex-cli-mcp]
command = "codex"
args = ["mcp-server"]
enabled = false

[mcp_servers.linear]
url = "https://mcp.linear.app/mcp"
enabled = true

[mcp_servers.trigger]
command = "npx"
args = ["trigger.dev@latest", "mcp"]
enabled = false

[mcp_servers.playwright]
args = ["@playwright/mcp@latest"]
command = "npx"

[notice]
hide_gpt5_1_migration_prompt = true
"hide_gpt-5.1-codex-max_migration_prompt" = true

[notice.model_migrations]
"gpt-5.2" = "gpt-5.2-codex"

I was able to restore the Desktop threads in app.

Timeline

1. Initially, only Codex Desktop threads showed in app and looked normal.
2. After an app reset/restart, all threads disappeared.
3. Tried sanitizing/quarantining oversized sessions (base64/image‑heavy), then CLI/VSCode threads started showing up in app, but desktop threads were still missing.
4. Normalized session metadata for desktop sessions (session_meta.source from appServer → vscode, leaving originator="Codex Desktop" unchanged).

→ After a full restart, all desktop threads reappeared.

What I tried

• Verified sessions exist and parse under ~/.codex/sessions
• Expanded active-workspace-roots in .codex-global-state.json
• Removed persisted cloud environment pinning
• Quarantined/sanitized large base64/image sessions
• Rebuilt history.jsonl + thread-titles
• Full quit/reopen cycles

What worked

• Normalizing Codex Desktop session metadata: source="appServer" → source="vscode", then restarting.

Possible repro (best‑effort, not fully confirmed)

1. Create multiple desktop sessions across project roots.
2. Include some large payloads (images/long outputs).
3. Restart the app.
4. Observe missing desktop threads; on disk, sessions still exist with

originator="Codex Desktop" + source="appServer".

Observations / logs

• Intermittent MCP server errors appeared in logs during the missing‑threads window (not confirmed causal).
• Pulled logs from ~/.codex/log and checked app local storage at:
• ~/Library/Application Support/Codex/Local Storage
• ~/Library/Application Support/Codex/Session Storage
• Did see a crash log with an auth refresh error: TokenRefreshFailed: Invalid client (timing overlapped with the missing‑threads window, not confirmed causal).
• Backed up all session files and global state before quarantining/sanitizing or rewriting metadata, so can share diffs of original vs. fixed files if that would help.

Config (sanitized, no custom model provider)

model = "gpt-5.2-codex"
model_reasoning_effort = "high"

[features]
unified_exec = true
steer = true
collaboration_modes = true

[sandbox_workspace_write]
network_access = true

# multiple trusted projects
[projects."..."]
trust_level = "trusted"

# MCP (tokens removed)
[mcp_servers.github]
command = "bunx"
args = ["-y", "@modelcontextprotocol/server-github"]
enabled = true

[mcp_servers.github.env]
GITHUB_PERSONAL_ACCESS_TOKEN = "<REDACTED>"

[mcp_servers.linear]
url = "https://mcp.linear.app/mcp"
enabled = true

[mcp_servers.shadcn]
command = "bunx"
args = ["shadcn@latest", "mcp"]
enabled = true

[mcp_servers.magic]
command = "bunx"
args = ["-y", "@21st-dev/magic@latest", "API_KEY=<REDACTED>"]
enabled = true

[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]
enabled = true

Also facing this exact same issue! Here is my codex config if that's helpful. Let me know if you want any other information about my setup. My setup should be pretty stock, haven't done much other that enable web search in the config file

model = "gpt-5.2-codex"
model_reasoning_effort = "high"
web_search = "live"

personality = "friendly"
sandbox_mode = "danger-full-access"
approval_policy = "never"
[projects."/Users/brycemorrow/Documents/code/current/magic-lines"]
trust_level = "trusted"

[projects."/Users/brycemorrow/Documents/code/current/portfolio"]
trust_level = "trusted"

[projects."/Users/brycemorrow/Documents/code/hourglass-foundation/stable-pre-deposit"]
trust_level = "trusted"

[projects."/Users/brycemorrow/Documents/code/hourglass-foundation"]
trust_level = "trusted"

[projects."/Users/brycemorrow/Documents/code/hourglass-foundation/hourglass-backend"]
trust_level = "trusted"

[projects."/Users/brycemorrow/Documents/code/hourglass-foundation/stack/hourglass-infrastructure"]
trust_level = "trusted"

[projects."/Users/brycemorrow/Documents/code/hourglass-foundation/stack"]
trust_level = "trusted"

[projects."/Users/brycemorrow/Documents/code/hourglass-foundation/stack/hourglass-backend"]
trust_level = "trusted"

[projects."/Users/brycemorrow/Documents/code/hourglass-foundation/stack/hourglass-backend/.git/modules/packages/cli"]
trust_level = "trusted"

[projects."/Users/brycemorrow/Documents/code/CodexMonitor"]
trust_level = "trusted"

[projects."/Users/brycemorrow/Documents/code/tools/CodexMonitor"]
trust_level = "trusted"

[projects."/Users/brycemorrow/Documents/code/hourglass-foundation/stack/stable-iusdt"]
trust_level = "trusted"

[mcp_servers.effect-docs]
command = "npx"
args = ["-y", "effect-mcp@latest"]

[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]

[mcp_servers.linear]
url = "https://mcp.linear.app/mcp"

[mcp_servers.playwriter]
command = "npx"
args = ["-y", "playwriter@latest"]

[features]
unified_exec = true
shell_snapshot = true
collab = true
steer = true
collaboration_modes = true
apps = false

@etraut-openai do you recommend i do what @roodboi did to resolve this?

@roodboi - any side effects? are those sessions that you sanitized re-visitable?

@human-bee the sanitize/quarantine stuff was me debugging, not a fix — I was just trying to see what was blocking indexing and whether I could surface any useful clues from my setup.

Sanitizing only made some CLI/VSCode threads show up but desktop threads didn’t return until I tweaked source/originator

It also had side effects: I hit invalid_encrypted_content (looks like compacted chunks), and deleting those can make the session too big/unstable, but fixed by re‑compacting with /compact.

I wouldn’t recommend trying to sanitize/mess with session meta etc. unless you have backed everything up and are okay with possible partial data loss.

That being said i do have my threads back in the UI now and haven't run into the issue again with any my new threads. The initial problem happened on previous builds: cli: 94 and app: 260202.0859 (build 517) and Im on cli: 95 and app: 260203.1501 (523) now.

This is resolved in the latest update for me. Version 260204.1342 (531). macOS 26.2 (25C56).