[BUG] Claude Desktop (Windows): system-tray icon invisible when app theme differs from the Windows taskbar mode — wrong-contrast glyph selected (mirror of #65343)

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/65343
2. https://github.com/anthropics/claude-code/issues/41236

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Would be happy to upvote any of those tickets, but they are closed

Vladimir

On Tue, Jun 30, 2026 at 3:59 PM github-actions[bot] <
@.***> wrote:

github-actions[bot] left a comment (anthropics/claude-code#72622) <https://github.com/anthropics/claude-code/issues/72622#issuecomment-4848589117> Found 2 possible duplicate issues: 1. #65343 <https://github.com/anthropics/claude-code/issues/65343> 2. #41236 <https://github.com/anthropics/claude-code/issues/41236> This issue will be automatically closed as a duplicate in 3 days. - If your issue is a duplicate, please close it and 👍 the existing issue instead - To prevent auto-closure, add a comment or 👎 this comment 🤖 Generated with Claude Code <https://claude.ai/code> — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/72622?email_source=notifications&email_token=ADDYHHQ4TV7NPAVNOS63HLD5CRA45A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBUHA2TQOJRGE32M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4848589117>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADDYHHSVIZBTPUXOV42RYS35CRA45AVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TINZYGA4TKNBTGQZ2C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/ADDYHHVODL5N66S7F7HHPPD5CRA45A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBUHA2TQOJRGE32M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/ADDYHHVT6WHSJA6LO4M772T5CRA45A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBUHA2TQOJRGE32M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: @.***>

Confirming this on the current build, in the opposite theme direction from the repro in the original post, and with measurements that I think correct the root-cause analysis in #65343 (which was closed as not planned).

Environment

| | |
|---|---|
| Claude Desktop | 1.30096.5.0 (MSIX, Claude_1.30096.5.0_x64__pzs8sxrjxfjjc) |
| Windows | 11 Pro, build 10.0.26200 |
| SystemUsesLightTheme | 0 — taskbar/tray is dark |
| AppsUseLightTheme | 1 — app windows are light |

Result: the tray glyph is black on a dark taskbar — effectively invisible.

Isolating the defect to the "System" appearance setting. Toggling Claude Desktop's own Settings → Appearance, with no Windows settings changed:

| Claude Desktop appearance | Electron themeSource | shouldUseDarkColors | Glyph | Against my dark taskbar |
|---|---|---|---|---|
| Dark | dark (forced) | true | white | correct |
| Light | light (forced) | false | black | invisible |
| System (default) | system | false — resolves AppsUseLightTheme = 1 | black | invisible |

This narrows it usefully:

• The assets load, and tray.setImage() works — the Dark row proves both. Nothing is corrupt or broken in the tray plumbing.
• The only failing path is how System is resolved. With themeSource: 'system', shouldUseDarkColors returns the app color mode, which is correct and documented behavior for window chrome — Electron is not misbehaving here. The defect is Claude Desktop reusing a window-theme signal to pick a shell-surface asset. The tray lives on the taskbar, so it must follow the taskbar's mode.
• System is the default appearance setting, so this hits users who have changed nothing in the app at all.
• It also means the two settings are wrongly coupled: today, the only way for me to get a visible tray icon is to force the entire app to Dark. A user who wants light app windows on a dark taskbar — a perfectly ordinary Windows 11 configuration — cannot have a visible tray icon at any setting.

The assets are not corrupt. #65343 attributed this to Tray-Win32-Dark.ico being "corrupt/transparent." That is not the case. I decoded both icons from the shipped package at 32x32 and measured the mean luminance of their opaque pixels:

| File | Opaque pixels | Mean luminance |
|---|---|---|
| resources\Tray-Win32.ico | 322 | 0 / 255 (pure black glyph) |
| resources\Tray-Win32-Dark.ico | 322 | 255 / 255 (pure white glyph) |

Identical coverage (322 px each), inverted color. Both files are valid and correctly drawn. This is a selection bug, not an asset bug — worth correcting since the asset theory appears to be why the earlier report was dismissed.

The selection logic. From resources\app.asar in 1.30096.5.0:

function ltr(e) {
  switch (`ico`) {
    case `ico`:
      return !e && o.nativeTheme.shouldUseDarkColors ? `Tray-Win32-Dark.ico` : `Tray-Win32.ico`;
    case `template-image`:
      return `TrayIconTemplate.png`;
    case `png`:
      return e || FFt() === `gnome` ...

The glyph is chosen from nativeTheme.shouldUseDarkColors. On Windows that reflects AppsUseLightTheme (the app color mode), but the surface the icon is drawn on — the taskbar — follows SystemUsesLightTheme (the Windows color mode). Those are two independent settings in Personalization → Colors, so whenever they differ the glyph is drawn at minimum contrast:

| Windows mode (taskbar) | App mode | Glyph chosen | Result |
|---|---|---|---|
| Light | Light | black | OK |
| Dark | Dark | white | OK |
| Light | Dark | white | invisible (the OP's case) |
| Dark | Light | black | invisible (my case) |

Both failing rows are the same defect. Note that the two working rows are the common configurations, which is likely why this survives internal use — a developer running matched modes never sees it.

Also worth noting: the switch scrutinee is the literal ` ico , so the template-image and png branches are unreachable in the shipped Windows bundle even though TrayIconTemplate*.png` assets ship alongside.

Suggested fix. Keep shouldUseDarkColors for window chrome, but for the tray specifically — and only when appearance is System — select on the shell theme:

HKCU\Software\Microsoft\Windows\CurrentVersion\Themes\Personalize\SystemUsesLightTheme

Read it at tray creation and re-read on WM_SETTINGCHANGE, calling tray.setImage() when it flips. Electron does not expose the shell theme separately today — that gap is electron/electron#46429 — so this needs a direct registry read on Windows.

An explicit Light or Dark appearance choice can keep overriding the tray as it does now, since that is a deliberate user instruction. Only the System path needs to change, which should make this a contained fix.

Accessibility framing: in both failing configurations the contrast ratio between glyph and taskbar is approximately 1:1, which is a complete loss of a persistent UI affordance rather than a cosmetic issue.

Workaround for anyone landing here: make the two settings match — Personalization → Colors, set app mode and Windows mode to the same value.