fix(linux): read indicator providers from new config path - #1
Open
gsim-inbolt wants to merge 1 commit into
Open
Conversation
The GNOME/Ubuntu indicator only looked at the legacy ~/.codexbar/config.json path. New CodexBar installs write to ~/.config/codexbar/config.json, so on those installs the file was absent and load_enabled_providers() silently fell back to the hardcoded [codex, claude] default -- ignoring the user's actual enabled/disabled provider toggles. Resolve the config path preferring the new XDG location and falling back to the legacy one, matching what the codexbar CLI itself does.
SebastienBreton
approved these changes
Jul 15, 2026
Owner
|
Seems very good to me |
Owner
|
Almost too good actually |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The GNOME/Ubuntu indicator reads its provider list from
~/.codexbar/config.jsononly. New CodexBar installs write their config to~/.config/codexbar/config.jsoninstead (the CLI already supports both paths). On a new-style install the legacy file is absent, soload_enabled_providers()silently falls back to the hardcoded["codex", "claude"]default and ignores the user's actual enabled/disabled toggles.Symptom: disabling a provider with
codexbar config disable --provider codexcorrectly drops it fromcodexbar usage, but the indicator keeps showing it (and shows Codex+Claude even when neither is enabled).Fix
Resolve the config path preferring the new XDG location (
~/.config/codexbar/config.json) and falling back to the legacy~/.codexbar/config.json, matching what thecodexbarCLI itself does. README config-path reference updated to mention both.Testing
python3 -c "import ast; ast.parse(...)"— syntax OKpyflakes— clean (matches thelinux-indicator.ymlCI lint)codexvia the CLI makes the indicator label go fromOx$0 Cl55/92toCl55/92on restart.