You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Investigate and fix Windows app icon showing blue box in production #62
I inspected the Windows packaging assets/config in apps/editor and found that the build is consistently wired to resources/win32/code.ico for the executable and installer:
apps/editor/resources/win32/VisualElementsManifest.xml → tile assets also point at resources/app/resources/win32/code_150x150.png and code_70x70.png
So the Windows pipeline is not missing an icon path — it is using one specific icon path everywhere.
The likely issue is the actual contents/quality of resources/win32/code.ico. The current .ico appears to be a single-frame ICO (Pillow only reports a single 256x256 image), which is a common cause of poor/fallback Windows icon rendering in packaged apps. Windows executables/installers generally behave best when the .ico contains multiple embedded sizes (for example 16, 24, 32, 48, 64, 128, 256) rather than just one large frame. A bad/incomplete ICO can show up as a blank/blue/fallback box in some production contexts even when the path/config is correct.
Also worth checking in the fix:
whether the branded OCcode icon asset was regenerated correctly from source artwork
whether the same replacement should be applied to installer/tile companion assets (code_70x70.png, code_150x150.png) to keep Windows branding consistent
whether any signing/build step is reusing a stale cached executable icon
Conclusion for now: primary suspected root cause is an incomplete or improperly generated Windows code.ico, not a missing config reference.
Next step will be to replace/regenerate the Windows icon set with a proper multi-size .ico and validate that macOS/Linux icon assets remain untouched.
Activity
damoahdominic commentedon Apr 3, 2026
Root-cause note from initial investigation:
I inspected the Windows packaging assets/config in
apps/editorand found that the build is consistently wired toresources/win32/code.icofor the executable and installer:apps/editor/build/lib/electron.ts→winIcon: "resources/win32/code.ico"apps/editor/build/gulpfile.vscode.win32.js→ stampsresources/win32/code.icointo the built.exeviarceditapps/editor/build/win32/code.iss→SetupIconFile={#RepoDir}\resources\win32\code.icoapps/editor/resources/win32/VisualElementsManifest.xml→ tile assets also point atresources/app/resources/win32/code_150x150.pngandcode_70x70.pngSo the Windows pipeline is not missing an icon path — it is using one specific icon path everywhere.
The likely issue is the actual contents/quality of
resources/win32/code.ico. The current.icoappears to be a single-frame ICO (Pillow only reports a single 256x256 image), which is a common cause of poor/fallback Windows icon rendering in packaged apps. Windows executables/installers generally behave best when the.icocontains multiple embedded sizes (for example 16, 24, 32, 48, 64, 128, 256) rather than just one large frame. A bad/incomplete ICO can show up as a blank/blue/fallback box in some production contexts even when the path/config is correct.Also worth checking in the fix:
code_70x70.png,code_150x150.png) to keep Windows branding consistentConclusion for now: primary suspected root cause is an incomplete or improperly generated Windows
code.ico, not a missing config reference.Next step will be to replace/regenerate the Windows icon set with a proper multi-size
.icoand validate that macOS/Linux icon assets remain untouched.