fix(desktop): persist backend-sourced skins so they survive restarts - #82483
Open
Shura0307 wants to merge 1 commit into
Open
fix(desktop): persist backend-sourced skins so they survive restarts#82483Shura0307 wants to merge 1 commit into
Shura0307 wants to merge 1 commit into
Conversation
Boot paint runs before the gateway connects and registers backend themes, so a backend-sourced skin (e.g. one set via display.skin, like sisyphus) could not be resolved on the first frame: normalizeSkin fell back to the default, and the connect-time seed deliberately never repainted. The user's picked skin name was stored, but every launch came back as the default. Two fixes in backend-sync.ts: - The connect-time seed now checks whether the pushed skin name matches the user's persisted choice and repaints it (finishing the pick, not stomping a manual switch). - Backend skins are converted and persisted as user themes in localStorage, so the NEXT boot's first paint resolves them synchronously like a built-in — no gateway-timing dependency, and no default flash on the connecting screen. Adds tests for seed recovery, per-profile persisted backend skins, and user-theme persistence.
Collaborator
lancecheney
pushed a commit
to lancecheney/hermes-agent
that referenced
this pull request
Aug 9, 2026
The `_micro_compact` docstring cited "NousResearch#82483" for the resume double-load problem. No such issue exists — the repository's highest number is 74323, so the reference was invented rather than looked up. The reasoning it was attached to is correct and stays: the session flush is append-only, so an in-memory splice alone leaves the original rows active and a resume loads both the summary and the messages it replaced. Only the citation was wrong. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
randlee
pushed a commit
to randlee/hermes-agent
that referenced
this pull request
Aug 11, 2026
The `_micro_compact` docstring cited "NousResearch#82483" for the resume double-load problem. No such issue exists — the repository's highest number is 74323, so the reference was invented rather than looked up. The reasoning it was attached to is correct and stays: the session flush is append-only, so an in-memory splice alone leaves the original rows active and a resume loads both the summary and the messages it replaced. Only the citation was wrong. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
33hodl
pushed a commit
to 33hodl/hermes-agent
that referenced
this pull request
Aug 12, 2026
The `_micro_compact` docstring cited "NousResearch#82483" for the resume double-load problem. No such issue exists — the repository's highest number is 74323, so the reference was invented rather than looked up. The reasoning it was attached to is correct and stays: the session flush is append-only, so an in-memory splice alone leaves the original rows active and a resume loads both the summary and the messages it replaced. Only the citation was wrong. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
10 tasks
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
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
A backend-sourced skin (e.g. one set via
display.skin, likesisyphus) does not survive a desktop restart. The picked skin shows while connected, but every launch comes back as the default.Root cause is a gateway-timing dependency: the desktop's boot-time paint runs before the gateway connects and registers backend themes, so the persisted skin name cannot be resolved on the first frame —
normalizeSkinfalls back toDEFAULT_SKIN_NAME. The connect-time seed (ingestBackendSkinwithapply: false) deliberately never repaints, so the default sticks for the whole session.This affects the whole class of backend-sourced skins (ares, daylight, warm-lightmode, poseidon, sisyphus, charizard — anything in
skin_engine.pybut not in the desktop'sBUILTIN_THEMES), not just one name. Built-in desktop skins are unaffected because they resolve locally on the first frame.Fix
Two changes in
apps/desktop/src/themes/backend-sync.ts:Seed recovery — on connect, if the pushed skin name matches the user's persisted choice, repaint it. This finishes the user's pick instead of stomping it (the guard for manual switches is untouched: a persisted name differing from the backend skin still never repaints).
User-theme persistence — backend skins are converted via
skinToDesktopThemeand installed as user themes (localStorage), so the next boot's first paint resolves them synchronously, exactly like a built-in. No timing dependency, and the connecting screen paints the right skin from frame one.Tests
backend-sync.test.tsgrows from 11 to 16 cases: seed recovery when the persisted skin equals the backend skin, per-profile persisted backend skins, no-apply when they differ, user-theme persistence to localStorage, and no rewrite when the persisted theme is unchanged.