Summary
A hand-edited config.json (adding glm-5.3 to the zai provider) was silently reverted by an ocx sync while the long-lived proxy server was running. The running server held the pre-edit config in memory; the sync-triggered service-time save serialized the stale copy over the disk file. This is the bug class from #488 (closed). In 2.21.0 the normal save path was fixed to re-read disk first (verified: a later service-time write preserved the hand-edit), but we have not confirmed whether the ocx sync write path was part of that fix or still uses the stale in-memory config.
Environment
- opencodex 2.21.0 (npm @bitkyc08/opencodex), Windows, service mode via scheduled task (opencodex-service.cmd wrapper, bun runtime, start --port 10101)
- Config at %USERPROFILE%.opencodex\config.json
Timeline (2026-08-15, America/New_York, EDT)
| Time |
Event |
| 14:02:56 |
Hand-edit applied to disk: glm-5.3 added to all six zai provider spots (models, modelContextWindows, modelReasoningEfforts, noVisionModels, preserveReasoningContentModels, modelReasoningEffortMap) |
| 14:03:05 |
ocx sync run against long-lived server (old PID 45428, started 8/13) |
| 14:04:46 |
config.json rewritten: tune gone; opencode-go/glm-5.3 auto-added to disabledModels |
| 14:21:56 / 14:22:08 |
Second re-apply, clobbered again by second ocx sync |
| 14:50:48 / 14:51:11 |
npm install -g @bitkyc08/opencodex@latest -> 2.21.0; startup migration rewrites config (qwen rename only; never touches zai) |
| 14:53:06 |
Service restart; new server (PID 55940) loads the already-reverted file (so the upgrade gets blamed for a loss that happened 46 minutes earlier) |
| 15:06:28 / 15:06:37 |
Third re-apply + ocx sync - this one survived, consistent with 2.21.0 save path re-reading disk before writing |
| 15:18:44 |
Another service-time write; tune still intact |
Evidence
- Backup diffs: pre-tune vs post-clobber differ ONLY by the disabledModels line; the tune appears in none of the backups because each backup was taken from already-clobbered or pre-tune state.
- config-mutation.sqlite records the writes (RCA copy retained).
- npm debug log confirms the 2.21.0 install completed at 14:51, after the first clobber at 14:04:46.
Ask
- Does the ocx sync path (and any other management/GUI write path) in current code re-read config from disk before saving, or can it still serialize a stale in-memory copy over a hand-edit?
- If the sync path still saves from memory, can it adopt the same disk-rebase approach as the fixed save path?
Impact / prevention on our side
Documented runbook guard: hand-edit -> restart proxy before any ocx sync/GUI toggle; snapshot -> validate -> diff after every upgrade/sync; config.json now git-tracked locally for one-command rollback.
Summary
A hand-edited config.json (adding glm-5.3 to the zai provider) was silently reverted by an ocx sync while the long-lived proxy server was running. The running server held the pre-edit config in memory; the sync-triggered service-time save serialized the stale copy over the disk file. This is the bug class from #488 (closed). In 2.21.0 the normal save path was fixed to re-read disk first (verified: a later service-time write preserved the hand-edit), but we have not confirmed whether the ocx sync write path was part of that fix or still uses the stale in-memory config.
Environment
Timeline (2026-08-15, America/New_York, EDT)
Evidence
Ask
Impact / prevention on our side
Documented runbook guard: hand-edit -> restart proxy before any ocx sync/GUI toggle; snapshot -> validate -> diff after every upgrade/sync; config.json now git-tracked locally for one-command rollback.