Preferences save always resets Codex to useApi: true, discarding the configured CLI command

[NAT23042004]

Summary

Saving preferences always resets the Codex provider to useApi: true, discarding a user-configured CLI command. On Linux this breaks the Codex panel entry, because the Direct API path needs an OpenAI web session token that is not available there.

useApi is read from the hardcoded PREDEFINED_PROVIDERS table rather than from the stored settings, so the saved value can never survive a preferences save.

Environment

• Extension: CodexBar codexbar@inled.es version 22 (also present at HEAD, 088f7f5)
• GNOME Shell 46, Wayland, Linux
• codexbar CLI 0.27.0 (linuxbrew), Codex CLI 0.149.0 with a valid ~/.codex/auth.json

Symptom

The Codex entry in the panel fails, and the journal shows:

[CodexBar] Fetching API summary for provider: Codex
[CodexBar] API error for provider Codex: Could not parse your authentication token. Please try signing in again.
    UsageApiError@.../usageApi.js:20:9
    _executeRequest@.../adapters/SoupApiFetcher.js:161:19
    _getJsonWithAuth@.../adapters/SoupApiFetcher.js:126:21
    fetch@.../adapters/SoupApiFetcher.js:76:41
    fetchSummary@.../usageApi.js:202:54

Meanwhile the same data is available locally without any web token:

$ codexbar usage --provider codex --source cli
== Codex 0.149.0 (codex-cli) ==
Session: 80% left
Weekly: 97% left
Plan: Plus

Root cause

In prefs.js:

• Line 23 hardcodes { id: "codex", name: "Codex", useApi: true, defaultCommand: "" }
• Line 510 sets row._useApi = info.useApi, taking the value from that table and never from the stored provider entry
• Line 468 writes useApi: row._useApi back into the providers setting on every save

createProviderRow already restores a stored command (the branch at lines ~487-495 keeps activeData.command when it contains --provider), so the command survives. The useApi flag does not get the same treatment, and it is the flag that decides routing: extension.js:344 (if (provider.useApi)) is the only branch between SoupApiFetcher and the CLI fetcher.

Net effect: a Linux user sets Codex to the CLI command, it works, then any later preferences save — toggling an unrelated provider, editing another command — silently flips Codex back to the API path and the panel breaks again.

Steps to reproduce

1. Set the Codex provider to the CLI route:

   gsettings --schemadir ~/.local/share/gnome-shell/extensions/codexbar@inled.es/schemas \
     set org.gnome.shell.extensions.codexbar providers \
     '[{"id":"codex","name":"Codex","command":"codexbar --provider codex --source cli --format json","useApi":false}]'
   

2. Confirm the Codex panel entry works.
3. Open the extension preferences, toggle any provider off and on again, close the dialog.
4. Read the setting back — Codex is "useApi":true and the panel shows the authentication token error.

Suggested fix

Prefer the stored value over the table default in createProviderRow:

row._useApi = activeData?.useApi ?? info.useApi;

That alone makes a user's choice persist for any provider.

Separately, worth considering whether useApi: true is the right default for Codex on non-macOS platforms. The codexbar CLI rejects the web source outside macOS (selected source requires web support and is only supported on macOS), so --source cli is the only working route there, and the current default sends every Linux user down a path that cannot succeed. A platform-aware default, or simply useApi: false with defaultCommand: "codexbar --provider codex --source cli --format json", would avoid the first-run failure. The Antigravity and Claude entries are already configured this way and work correctly.

Workaround

Patch line 23 locally to useApi: false with the CLI defaultCommand. This is overwritten on every extension update.

[LexGear]

Is this the reason why changing any settings causes it to break and show the message "Error: Failed to retrieve access token from session. Cookies might be invalid" or something similar.