Windows Desktop: Settings “Open config.toml” does nothing on fresh install/state reset

Windows Desktop app remains unreliable after reinstall / state reset: config open does nothing, tray/UI issues, WSL cwd/state issues, generated images not saved

Summary

The Windows Codex Desktop app does not work reliably on my machine even after uninstalling/reinstalling and resetting user state.

The most reproducible fresh-install issue is:

Settings → Agent → config.toml → Open does nothing.

The file exists and Windows can open it normally, so this does not appear to be a missing file or broken file association.

In addition to that, I have also hit multiple Windows Desktop state/path issues:

• tray icon / tray behavior appears broken even after reinstall
• WSL mode has produced invalid working-directory state
• restored threads can appear temporarily and then disappear again after restart/click
• generated images are not reliably placed into the expected generated_images folder
• previous bad state survived ordinary reinstall/reset attempts unless multiple user-state locations were manually removed

This makes the Windows Desktop app feel very fragile around user state, path translation, and file/open actions.

Environment

• OS: Windows
• App: Codex Desktop
• Package identity: OpenAI.Codex
• Installed app path observed:

C:\Program Files\WindowsApps\OpenAI.Codex_26.616.3309.0_x64__2p2nqsd0c76g0\app\resources

• Extracted desktop bundle version from package.json:

26.616.30709

Fresh reset/reinstall attempts included removing/recreating:

C:\Users\Imi\.codex

The app recreated a default config.toml.

Repro: Open config.toml does nothing

1. Install Codex Desktop on Windows.
2. Launch the app.
3. Let it create the default user config.
4. Open Settings.
5. Go to Agent / config section.
6. Click Open config.toml.

Expected

Codex should open or reveal:

C:\Users\Imi\.codex\config.toml

Actual

Nothing visible happens.

No editor opens, Explorer does not reveal the file, and no visible error is shown in the UI.

Local verification

The file exists:

C:\Users\Imi\.codex\config.toml

Windows can open it normally outside Codex. These both succeed from PowerShell:

Start-Process C:\Users\Imi\.codex\config.toml
Invoke-Item C:\Users\Imi\.codex\config.toml

So the issue does not appear to be that the file is missing or that Windows cannot open .toml files.

Related reliability issues seen on the same install

1. WSL mode generated / persisted invalid cwd paths

In WSL mode, Codex Desktop produced or persisted malformed working-directory paths shaped like:

/mnt/c/Program Files/WindowsApps/.../app/resources/C:\Users\Imi\...

The real workspace existed at the normal WSL path:

/mnt/c/Users/Imi/...

This caused “Current working directory missing” style failures.

This was not just config.toml; it appeared to involve persisted Desktop state such as SQLite/global/session metadata.

2. Threads can disappear after restore / restart

Restoring old sessions by copying .codex back can make threads show temporarily, but after restarting or clicking them, they can disappear again.

From troubleshooting, this appears related to Codex Desktop needing consistency across multiple layers:

.codex/state_5.sqlite
.codex/.codex-global-state.json
.codex/sessions/**/*.jsonl
.codex/archived_sessions/**/*.jsonl

If threads.cwd, threads.sandbox_policy, rollout JSONL cwd/workspace metadata, and global workspace hints disagree, Desktop can lose or hide threads.

3. Generated images are not reliably copied to generated_images

Generated image output is not reliably appearing in the expected generated_images folder in either Windows-native or WSL mode.

I do not see a config.toml setting controlling this, so this looks like Desktop/runtime artifact handling or workspace/output-directory state.

Settings button computes <codexHome>\config.toml

File:

work/app-extract/webview/assets/open-config-toml-button-B6LBn2fN.js

Observed behavior:

• gets codexHome
• computes path.join(codexHome, "config.toml")
• sends an open-file request

codexHome comes from a desktop/backend RPC

File:

work/app-extract/.vite/build/main-Z4Ntf7SL.js

Relevant logic:

"codex-home": async e => {
  let n = this.getRequestAppServerClient(e.hostId),
      r = n.hostConfig,
      i = r.id === "local" && this.shouldUseWslPaths(),
      a = await n.platformPath(),
      o = t.Ta(r) ? await n.codexHome() : t.Pr({ preferWsl: rF });
  return { codexHome: F(o, i), worktreesSegment: F(a.join(o, "worktrees"), i) };
}

open-file is implemented in the desktop main process

File:

work/app-extract/.vite/build/main-Z4Ntf7SL.js

Relevant logic:

"open-file": async ({ path:e, target:n, appPath:r, line:i, column:o, cwd:s, ... }) => {
  try {
    ...
    let x = this.resolveOpenFilePath(h, g)
    ...
    await ZN(E, A, x, { appPath:r, detectedCommand:A===n?D:void 0, hostConfig:p, location:w, remotePath:N, remoteWorkspaceRoot:v })
    return { success: !0 }
  } catch (e) {
    return aF().error("Failed to open file", { safe:{}, sensitive:{ error:e } }), { success: !1 }
  }
}

So the button is wired to a real handler, and failures should be logged or surfaced.

Windows file-manager/system-open path uses Electron shell APIs

File:

work/app-extract/.vite/build/main-Z4Ntf7SL.js

Relevant logic:

async function gM(e) {
  let { shell:t } = await import("electron"), n = _M(e);
  if (n && statSync(n).isFile()) {
    t.showItemInFolder(n);
    return;
  }
  let r = n ?? e, i = await t.openPath(r);
  if (i) throw Error(i);
}

Current hypothesis

The app has several reliability issues around Desktop state, path resolution, and UI/open-file handling.

For the config.toml button specifically, likely possibilities are:

1. codex-home returns a bad or translated path.
2. open-file target/path resolution chooses a bad path or target.
3. shell.openPath / showItemInFolder fails, but the UI does not surface the error.
4. WSL path-translation logic is applied when it should not be.
5. open-file returns { success: false }, but the Settings UI ignores it.

For the broader Desktop issues, it seems Codex user state is split across several files and databases, and reinstalling the app does not reliably reset or repair that state.

What would help

• Surface the actual open-file error in the UI or logs.
• Log the live codexHome value when clicking Open config.toml.
• Verify the Windows Desktop fresh-install path for config.toml.
• Add a proper “Reset Desktop app state” option that clears or repairs all relevant per-user Desktop state.
• Add migration/repair logic for malformed Windows/WSL cwd values.
• Ensure Desktop sidebar/thread state remains consistent across:

• SQLite threads.cwd
• SQLite threads.sandbox_policy
• rollout JSONL metadata
• global workspace/root hints
• Document exactly which Windows user-state folders must be removed for a truly clean reinstall.