Summary
Short version first. More technical details below.
Doki Theme can get stuck in a partially installed CSS state on Windows where:
/* EmptyEditor Image */ exists/* Stickers */ exists/* Background Image */ is missing
When that happens, the wallpaper / glass-like transparency effect disappears from the main workbench/editor area, while the empty-editor background and stickers still remain.
In this state, normal Doki recovery flows may fail to rebuild the missing Background Image layer.
Environment
- VS Code: Stable on Windows
- Doki Theme:
unthrottled.doki-theme 88.1.18
- OS: Windows
Visible behavior
The theme looked only partially broken:
- stickers still worked
- empty editor background still worked
- the main wallpaper/transparency layer was gone
So the extension still appeared active, but one critical visual layer was missing.
Concrete broken state
In workbench.desktop.main.css, the broken state was:
/* EmptyEditor Image */ present/* Stickers */ present/* Background Image */ missing
In the working state, all three blocks were present.
The missing transparency effect mapped directly to the missing /* Background Image */ block.
Recovery actions that did not fix it
In my case, these did not restore the missing layer:
- toggling
doki.wallpaper.enabled
- reloading the VS Code window
- using Doki restore/install flows
- reinstalling/reapplying wallpaper through normal commands
The config could indicate wallpaper was enabled, while the generated CSS still remained in the partial state above.
Technical observations
1. Wallpaper and empty-editor background are generated separately
From the installed extension code, these appear to be separate CSS generation paths, mainly around:
StickerServicebuildWallpaperCss(...)buildBackgroundCss(...)buildCSSWithWallpaperAndBackground(...)
That matches the broken behavior: one layer can disappear while the other remains.
2. ConfigWatcher does not appear to watch the enable flags
It looks like ConfigWatcher reacts to changes such as:
doki.sticker.pathdoki.sticker.cssdoki.background.pathdoki.wallpaper.pathdoki.background.anchor
But not to:
doki.wallpaper.enableddoki.background.enabled
If that reading is correct, toggling those settings may not trigger the rebuild users expect.
3. Recovery appears too dependent on current CSS markers
AutoInstaller seems to infer restore state from markers already present in the generated CSS, especially for wallpaper.
That makes recovery fragile once the CSS has already drifted into a partial state.
If /* Background Image */ is already missing, recovery may not reconstruct the full CSS state correctly.
Why this looks like a recovery/architecture bug
This did not look like an asset problem.
The issue was:
- settings looked valid
- some Doki layers were still installed
- one critical Doki CSS block was missing
- normal Doki commands did not fully restore it
That suggests the extension can enter a partially broken installed state and then fail to recover idempotently.
What fixed it manually
The issue was resolved only after manually restoring a Doki-compatible /* Background Image */ block into workbench.desktop.main.css.
As soon as that block was restored, the transparency/wallpaper effect came back.
That strongly suggests the problem is in CSS regeneration/recovery, not in the assets themselves.
Suggested fix direction
Possible directions:
-
Make ConfigWatcher also react to:
doki.wallpaper.enableddoki.background.enabled
-
Make restore/install flows rebuild the full Doki CSS state from settings, instead of depending on the current CSS markers too heavily.
-
Make restore/install operations idempotent:
- if any expected Doki block is missing, rebuild the complete set
-
Consider validating the expected full installed state:
Background ImageEmptyEditor ImageStickers
instead of partially inferring state from whatever blocks remain.
Note
I am not claiming this is the only repro path, only that this partial state is possible and normal recovery did not repair it.
This report was drafted with AI assistance after a broken custom Doki setup and multiple recovery attempts. I reviewed it before posting, but I may not be able to answer detailed follow-up questions about the extension internals.
Summary
Short version first. More technical details below.
Doki Theme can get stuck in a partially installed CSS state on Windows where:
/* EmptyEditor Image */exists/* Stickers */exists/* Background Image */is missingWhen that happens, the wallpaper / glass-like transparency effect disappears from the main workbench/editor area, while the empty-editor background and stickers still remain.
In this state, normal Doki recovery flows may fail to rebuild the missing
Background Imagelayer.Environment
unthrottled.doki-theme88.1.18Visible behavior
The theme looked only partially broken:
So the extension still appeared active, but one critical visual layer was missing.
Concrete broken state
In
workbench.desktop.main.css, the broken state was:/* EmptyEditor Image */present/* Stickers */present/* Background Image */missingIn the working state, all three blocks were present.
The missing transparency effect mapped directly to the missing
/* Background Image */block.Recovery actions that did not fix it
In my case, these did not restore the missing layer:
doki.wallpaper.enabledThe config could indicate wallpaper was enabled, while the generated CSS still remained in the partial state above.
Technical observations
1. Wallpaper and empty-editor background are generated separately
From the installed extension code, these appear to be separate CSS generation paths, mainly around:
StickerServicebuildWallpaperCss(...)buildBackgroundCss(...)buildCSSWithWallpaperAndBackground(...)That matches the broken behavior: one layer can disappear while the other remains.
2.
ConfigWatcherdoes not appear to watch the enable flagsIt looks like
ConfigWatcherreacts to changes such as:doki.sticker.pathdoki.sticker.cssdoki.background.pathdoki.wallpaper.pathdoki.background.anchorBut not to:
doki.wallpaper.enableddoki.background.enabledIf that reading is correct, toggling those settings may not trigger the rebuild users expect.
3. Recovery appears too dependent on current CSS markers
AutoInstallerseems to infer restore state from markers already present in the generated CSS, especially for wallpaper.That makes recovery fragile once the CSS has already drifted into a partial state.
If
/* Background Image */is already missing, recovery may not reconstruct the full CSS state correctly.Why this looks like a recovery/architecture bug
This did not look like an asset problem.
The issue was:
That suggests the extension can enter a partially broken installed state and then fail to recover idempotently.
What fixed it manually
The issue was resolved only after manually restoring a Doki-compatible
/* Background Image */block intoworkbench.desktop.main.css.As soon as that block was restored, the transparency/wallpaper effect came back.
That strongly suggests the problem is in CSS regeneration/recovery, not in the assets themselves.
Suggested fix direction
Possible directions:
Make
ConfigWatcheralso react to:doki.wallpaper.enableddoki.background.enabledMake restore/install flows rebuild the full Doki CSS state from settings, instead of depending on the current CSS markers too heavily.
Make restore/install operations idempotent:
Consider validating the expected full installed state:
Background ImageEmptyEditor ImageStickersinstead of partially inferring state from whatever blocks remain.
Note
I am not claiming this is the only repro path, only that this partial state is possible and normal recovery did not repair it.
This report was drafted with AI assistance after a broken custom Doki setup and multiple recovery attempts. I reviewed it before posting, but I may not be able to answer detailed follow-up questions about the extension internals.