GUI: Stale error message on Startup Safety page after successful alternative installation

[ideabib]

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

1. Open the dashboard's Startup Safety page on Windows as a standard user.
2. Click Install on the Codex launcher shim.
3. Observe it fail with Exit code 199.
4. Run ocx service install from an elevated CLI to successfully protect the proxy.
5. Refresh the GUI dashboard page.
6. 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.

[github-actions]

_{Automated translation bookkeeping — detected language: English.}

[github-actions]

Issue reopened

The report now contains the information required by the automated check. Thanks for updating it.

[lidge-jun]

Fixed on dev by #1275 (merge 671a0df77).

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 serviceViable rather 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.

main does not carry this yet — it ships in the next release.