Repository navigation
GUI: Stale error message on Startup Safety page after successful alternative installation #1245
Description
Client or integration
OpenCodex dashboard
Area
Dashboard
Summary
On the Startup Safety page in the dashboard, if a user attempts to install the "Codex launcher shim" or background service via the GUI and it fails (e.g., due to Task Scheduler elevation requirements, throwing Exit code 199), an error message is correctly displayed.
However, if the user subsequently uses the CLI to successfully install the native background service (e.g., ocx service install), the top banner correctly updates to "Restart protected", but the stale error message below the shim section is never cleared from the UI.
The UI should clear any lingering installation error messages from previous attempts to prevent confusion.
Reproduction
- Open the dashboard's Startup Safety page on Windows as a standard user.
- Click Install on the Codex launcher shim.
- Observe it fail with Exit code 199.
- Run ocx service install from an elevated CLI to successfully protect the proxy.
- Refresh the GUI dashboard page.
- Observe the top banner correctly reads "Restart protected", but the bottom section still displays the stale Exit code 199 error from step 3.
Version
2.10.2
Operating system
Windows 11
Provider and model
No response
Logs or error output
No response
Screenshots and supporting files
No response
Redacted configuration
No response
Checks
- I searched existing issues and documentation.
- I removed secrets, tokens, account details, request credentials, and personal data.
Activity
github-actions commentedon Aug 7, 2026
Automated translation bookkeeping — detected language: English.
github-actions commentedon Aug 7, 2026
Issue reopened
The report now contains the information required by the automated check. Thanks for updating it.
Merge pull request #1275 from lidge-jun/codex/260808-1245-startup-sta…
lidge-jun commentedon Aug 8, 2026
Fixed on
devby #1275 (merge671a0df77).The failure notice now yields when health independently shows that attempt succeeded. The check is per action rather than on overall status, because a machine protected by the service must not erase a failed shim install that is still true — and it uses
serviceViablerather than installed-and-running, since a stale service can be both while the page still reports it unhealthy.Success confirmations are untouched; those are the receipt for an action you just ran.
Thanks for the report — the contradiction you described was exactly reproducible.
maindoes not carry this yet — it ships in the next release.fix(gui): clear a stale install failure once that action succeeded (l…
fix(gui): clear a stale install failure once that action succeeded (l…
Merge pull request lidge-jun#1275 from lidge-jun/codex/260808-1245-st…