fix(theme): composer + user card bg use theme tokens, not hardcoded #1e1e1e#1623
Merged
Conversation
…1e1e1e iTerm2 light theme + reasonix theme `github-light` still rendered the composer dock as a black band (#1607). The composer and the user-message card both hardcoded `#1e1e1e` for their bg and `#0153e5` for the brand accent — the proxy-tokens system (`SURFACE.bgInput`, `TONE.brand`) was bypassed entirely, so theme switches did nothing to either surface. What looked in the screenshots like "the status bar is also black" is actually `PromptInput`'s inline mode/model row, which lives *inside* the dark Box. The real `<StatusRow>` rendered below it with no bg and stayed themed correctly all along. Replaces four hardcoded literals with their theme tokens: - composer left accent stripe #0153e5 → TONE.brand - composer body bg #1e1e1e → SURFACE.bgInput - composer inline mode label color #0153e5 → TONE.brand - user message card bg #1e1e1e → SURFACE.bgInput All six themes already define matching `bgInput` values, so dark themes get the same near-black they had before and light themes (`light`, `github-light`) get the near-white they were missing. EditConfirm + SplitDiff still tint diff lines with hardcoded dark red/green and will need new `diffAddedBg`/`diffRemovedBg` tokens for light-theme parity — separate PR. Closes #1607
d25c7a6 to
976c041
Compare
This was referenced May 23, 2026
esengine
pushed a commit
that referenced
this pull request
Jun 8, 2026
…ation paths (#3436) * fix(desktop): clear active workspace pointer when removing current project RemoveWorkspace() was cleaning up desktop-workspaces.json and desktop-projects.json but never cleared the desktop-workspace pointer file. When the removed project was the active workspace, this left a stale reference that caused subsequent sessions to use the wrong workspace root — attachments and memory would land in a deleted project's directory. Now RemoveWorkspace checks whether the removed dir matches the active pointer and either falls back to the first remaining project or clears the pointer entirely when no projects remain. Fixes #1623 * fix(desktop): update active workspace pointer in OpenProjectTab SwitchWorkspace correctly saves the active pointer, but clicking an existing project in the sidebar goes through OpenProjectTab instead, which never called saveWorkspace. This meant that after switching projects via the sidebar, desktop-workspace still pointed to whichever project was active at app startup — causing attachments and memory to land in the wrong project directory. Now OpenProjectTab also calls saveWorkspace so the pointer stays in sync regardless of how the user navigates between projects. Also adds a test verifying OpenProjectTab updates the pointer.
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
1 participant
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.
Closes #1607.
What the user saw
On macOS iTerm2 with a light terminal profile and Reasonix
theme: github-light, the bottom of the TUI rendered as a wide black band, with low-contrast text on top:What's actually going on
What reads visually as "input box + status bar both black" is a single offending Box in
PromptInput.tsx. Four hardcoded color literals were bypassing the proxy-tokens theme system entirely:PromptInput.tsx:212#0153e5PromptInput.tsx:213#1e1e1ePromptInput.tsx:339#0153e5cards/UserCard.tsx:14#1e1e1eThe inline
mode · modelrow (审查 · Auto · Deepseek v4 flashin the screenshot) lives inside the same#1e1e1eBox as the composer body, which is why the user perceived it as the status bar being black. The real<StatusRow>is below that, has nobackgroundColor, and was already themed correctly — it just sits on the terminal default bg.Fix
Swap the four literals for their theme tokens:
All six themes (
default,dark,light,tokyo-night,github-dark,github-light,high-contrast) already definebgInput, so dark-theme users get the same near-black they had (#0d1015/#111827/#1f2335/#0a0a0a— close enough to the old#1e1e1e), and light-theme users get the near-white they were missing (#f6f8fa/#f8fafc).Out of scope (follow-up)
EditConfirm.tsxandSplitDiff.tsxstill tint diff add/remove lines with hardcoded#2a1212(dark red) and#0c2718(dark green). On a light theme those read as near-black blocks, equally broken. Fixing them needs new theme tokens (diffAddedBg/diffRemovedBg) with per-theme values, so I'm leaving that for a separate PR.Test plan
npm run typecheckcleannpm run lintclean (only pre-existing warning in welcome-banner-hints)npm run test— 3586 pass"theme": "github-light"in config, confirm composer + user card render on near-white bg, blue accent stripe present, mode label "审查" visible