Repository navigation
Aside integration profiles silently go off (stale), breaking sidecar sync (no auto-recovery, client sync no-ops) #6757
Description
Summary
After an ocx sync / Codex app restart cycle, the managed Aside integration profiles end up off (stale) and the OpenCodex sidecar provider/login config is no longer injected into Aside. ocx integration client sync --client aside then no-ops because disabled profiles aren't eligible, so there's no obvious recovery path short of a manual integration client enable.
Observed on macOS (home Mac), OpenCodex.app standalone runtime (/Applications/OpenCodex.app/Contents/MacOS/ocx), Codex 0.160.1.
What I saw
ocx integration client status --client aside:
0 bitkyc07: off (stale) [current]
1 Local Account: off (stale)
2 Local Account: off (stale)
ocx integration client sync --client aside:
No eligible Aside profiles to synchronize. Check integration status and profile sync preferences.
ocx integration native shows claude/grok/codex/claude-desktop all current / on, so only the Aside client fell out of sync.
ocx status is otherwise healthy:
Proxy: running (PID ...), Health ... ok (live)
Runtime source: standalone
routing=opencodex-local, service=absent, shim=absent
(Also surfaces Restart safety: AT RISK ... run 'ocx service install' and Codex autostart shim is not installed — possibly related, since there's no viable background service to keep integrations fresh across restarts.)
Likely cause
- Aside profiles were marked
stale(owner/attestation drift) and then flippedoff, but nothing re-enables them automatically. integration client sync --client asideonly refreshes already-enabled profiles, so once they'reoffit reports "No eligible Aside profiles" instead of offering to re-enable or pointing atintegration client enable.- Compounding: the Aside cloud account (
bitkyc07@gmail.com) is signed out withdevice mismatch, which also makesaside exec(built-in models) fail with a 400, whileaside repl(direct browser) still works. The ocx-sideoff (stale)and the Aside-side sign-out look correlated.
Expected
integration client sync --client aside(orocx doctor) should detectoff (stale)profiles and either re-apply them or clearly tell the user to runintegration client enable --client aside --profile N.- Ideally, the sidecar integration should survive an
ocx sync --restart-codex/ app relaunch without silently going stale.
Workaround
Manual re-enable:
ocx integration client preview --client aside --operation apply --profile 0
ocx integration client enable --client aside --profile 0
(preview fingerprint p2:15b1dbef33ed299ae3ff59b9767c76ad, change = replace providers.opencodex).
Environment
- OpenCodex.app runtime: standalone (also npm
@bitkyc08/opencodex@2.7.43installed under nvm, not running) - Codex 0.160.1, macOS (Apple Silicon)
- proxy port 10100
Activity
fix(cli): name the reviewed recovery for Aside profiles that read off…
lidge-jun commentedon Oct 9, 2026
Fixed on
devby #6825 (merge commit d5d6f9b).ocx integration client sync --client asideno longer ends in a bare no-op when it finds no eligible profiles. It explains that sync refreshes only profiles whose sync preference is on. It also namesocx integration client status --client asideand the preview-then-enable commands.ocx integration client status --client aside(list or--profile N) prints the preview and enable commands with the real ID for each profile that isoff (stale). Nothing is re-enabled automatically, so an OFF preference stays authoritative.asideProfileSyncblock still loads as "all profiles off", but the config load now warns about it once.Cause: not proven. No automatic stale, fingerprint, attestation or restart path turns an explicit
truepreference intofalse. That leaves four possible causes. Telling them apart would need the affected runtime'sasideProfileSyncblock and its Aside ownership records.OPENCODEX_HOME.The other expectation in this issue, that the sidecar integration should survive an
ocx sync --restart-codexor app relaunch, is not covered by this change. The cause above is still open.lidge-jun commentedon Oct 9, 2026
Reopening: I closed this too early. #6825 adds the recovery guidance and the warning for a malformed policy. What remains is the cause of profiles going
off (stale)without a user action, and whether they should survive a restart. To narrow it down, we need the affected machine'sasideProfileSyncblock (fromconfig.json) and the output ofocx integration client status --client aside --json. Once the cause is fixed or ruled out, this can be closed.