settings shows true routing state: live refresh + Bun.TOML parse fallback - #25
Open
dallascrilley wants to merge 3 commits into
Open
settings shows true routing state: live refresh + Bun.TOML parse fallback#25dallascrilley wants to merge 3 commits into
dallascrilley wants to merge 3 commits into
Conversation
The dashboard received routing once at launch (options.routing) and never re-read it, so Settings kept showing the launch-time snapshot for the whole session. Routing actually lives in the harness config files and can change while the dashboard is open — tokenmaxx install/uninstall from another shell, first-login auto-enable, or the daemon's post-update heal — leaving Settings contradicting the on-disk config (e.g. showing codex routing off while model_provider still points at the proxy). reload() now re-reads installStatus() alongside piStatus(), so the 2s tick and manual refresh both bring the display back to the files' truth, and the routing toggle flips from the live value instead of the stale snapshot.
Bun.TOML.parse rejects bare table keys that start with a digit — a real-world example is [mcp_servers.1password], which codex itself writes and accepts. On any config containing such a table, installStatus() threw into its catch and reported codexRouted = false no matter what the file actually said. The visible damage: the dashboard's Settings page showed codex routing off while model_provider = "tokenmaxx" was actively sending traffic through the proxy, and pressing the routing toggle computed enable from that wrong false and re-installed the managed block instead of removing it — turning routing off through the dashboard was impossible on such a config. On parse failure, fall back to detecting our own active selection line (commented-out lines never match). The semantic TOML check stays the primary path for configs that parse.
dallascrilley
changed the title
The parse-failure fallback matched our selection line anywhere in the file, but a model_provider under a table belongs to that table: a legacy selection swallowed into [notice], or a [profiles.x] naming our provider while another is active, would read as routed — and healInstalledConfigs would re-enable routing from that. Scan only the region before the first table header. Also pin that the installed fixture genuinely breaks Bun.TOML, so the regression test keeps exercising the fallback if bun's parser improves.
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
1 participant
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
Settings was showing codex routing off while
~/.codex/config.tomlhad an activemodel_provider = "tokenmaxx"and all codex traffic flowed through the proxy. Worse, pressing the routing toggle to turn it off computedenablefrom that wrongfalseand re-installed the managed block — turning routing off through the dashboard was impossible.Two compounding causes, one commit each:
1.
installStatus()reportedcodexRouted = falseforever on real-world configsBun.TOML.parserejects bare table keys that start with a digit — e.g.[mcp_servers.1password], which codex itself writes and accepts. Repro on bun 1.3.14:Any config containing such a table threw into
installStatus()'scatch, which returnedcodexRouted = falseregardless of what the file actually said. Fix: on parse failure, fall back to detecting our own active selection line, scanning only the top-level region (amodel_providerunder a table belongs to that table, so swallowed legacy blocks and[profiles.x]entries can't false-positive intohealInstalledConfigsre-enabling routing). The semantic TOML check stays the primary path for configs that parse. Regression tests cover the parse failure both directions, the swallowed-legacy case, and the profile case.2. The dashboard's routing display was a launch-time snapshot
runTuiDashboardreceivedroutingonce fromrunCliand never re-read it, so any out-of-band change —tokenmaxx install/uninstallfrom another shell, first-login auto-enable inlogin(), the daemon's post-update heal — left Settings contradicting the files for the rest of the session. Fix:reload()re-readsinstallStatus()alongside the existingpiStatus()call, so the 2s tick and manualrrefresh converge the display to the files' truth, and the toggle flips from live state.Testing
bun test— 89 pass, 0 fail (2 new regression tests for the parse-failure fallback)bun run typecheck— cleanbun x biome check— cleanNot addressed here
While debugging we also found that Codex desktop (ChatGPT app 26.831.20005) attaches no agent tools to turns when
model_provideris a custom provider — the model runs chat-only. The proxy forwards tool definitions correctly (verified with direct requests, andcodexCLI 0.152.0 executes shell fine through tokenmaxx), so this looks like desktop-side capability negotiation for custom providers, not something tokenmaxx can fix. Flagging in case you want to document it as a known limitation of codex routing.