Right-click a folder and pick one of the twelve colours the calendar already uses, or clear it again. The colour tints the folder's icon; the label keeps the sidebar's own contrast, which a dozen arbitrary colours would not reliably give it.
The swatch grid is the same one the calendar's event menu uses, so the two feel like one app rather than two features that both happen to involve colour.
Two decisions worth your eye
Kept by mailbox id, not by name. A folder that gets renamed, or dragged somewhere else, keeps its colour.
Stored in settings, which live in this browser. JMAP has nowhere on a Mailbox to put a colour, and there is no Stalwart registry object for it either — so this cannot sync without inventing a place to keep it. Every other colour in the app already works this way: labels, event categories, the accent. So it is consistent, but it is per-device, and someone who signs in elsewhere gets the defaults back. If that matters, the honest fix is a place to store client preferences server-side, which is a much larger change than a context menu.
One bug this nearly shipped with
.nav-item svg sets the colour on the icon element itself, so a colour inherited from a wrapping span does nothing. My first check read getComputedStyle on the wrapper, which reported the chosen purple — while the rendered pixels stayed grey. The rule now targets the svg directly, and the verification reads the pixels:
Same shape of mistake as the light-theme screenshot earlier today — checking the DOM instead of the frame — so it seemed worth naming rather than quietly fixing.
Verified
In the running app: twelve swatches offered, picking one tints that folder and no other, the colour survives a reload, and "Use the default colour" clears it. npm run typecheck, npm test — 224 web + 88 server passing, including cases for the id-keyed lookup.
Right-click a folder and pick one of the twelve colours the calendar already uses, or clear it again. The colour tints the folder's **icon**; the label keeps the sidebar's own contrast, which a dozen arbitrary colours would not reliably give it.
The swatch grid is the same one the calendar's event menu uses, so the two feel like one app rather than two features that both happen to involve colour.
## Two decisions worth your eye
**Kept by mailbox id, not by name.** A folder that gets renamed, or dragged somewhere else, keeps its colour.
**Stored in settings, which live in this browser.** JMAP has nowhere on a `Mailbox` to put a colour, and there is no Stalwart registry object for it either — so this cannot sync without inventing a place to keep it. Every other colour in the app already works this way: labels, event categories, the accent. So it is consistent, but it is per-device, and someone who signs in elsewhere gets the defaults back. If that matters, the honest fix is a place to store client preferences server-side, which is a much larger change than a context menu.
## One bug this nearly shipped with
`.nav-item svg` sets the colour on the icon element itself, so a colour inherited from a wrapping span does nothing. My first check read `getComputedStyle` on the wrapper, which reported the chosen purple — while the rendered pixels stayed grey. The rule now targets the `svg` directly, and the verification reads the **pixels**:
```
before: #48505D #9AA2AF (the sidebar's muted grey)
after: #6450AB #42317A (antialiased #7c3aed)
```
Same shape of mistake as the light-theme screenshot earlier today — checking the DOM instead of the frame — so it seemed worth naming rather than quietly fixing.
## Verified
In the running app: twelve swatches offered, picking one tints that folder and no other, the colour survives a reload, and "Use the default colour" clears it. `npm run typecheck`, `npm test` — 224 web + 88 server passing, including cases for the id-keyed lookup.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
**Merged** 2026-08-25 as coffey-labs/ihasmail@aad599d8022b
<sub>Rebuilt from: git history, session transcript.</sub>
This repo is archived. You cannot comment on issues.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Right-click a folder and pick one of the twelve colours the calendar already uses, or clear it again. The colour tints the folder's icon; the label keeps the sidebar's own contrast, which a dozen arbitrary colours would not reliably give it.
The swatch grid is the same one the calendar's event menu uses, so the two feel like one app rather than two features that both happen to involve colour.
Two decisions worth your eye
Kept by mailbox id, not by name. A folder that gets renamed, or dragged somewhere else, keeps its colour.
Stored in settings, which live in this browser. JMAP has nowhere on a
Mailboxto put a colour, and there is no Stalwart registry object for it either — so this cannot sync without inventing a place to keep it. Every other colour in the app already works this way: labels, event categories, the accent. So it is consistent, but it is per-device, and someone who signs in elsewhere gets the defaults back. If that matters, the honest fix is a place to store client preferences server-side, which is a much larger change than a context menu.One bug this nearly shipped with
.nav-item svgsets the colour on the icon element itself, so a colour inherited from a wrapping span does nothing. My first check readgetComputedStyleon the wrapper, which reported the chosen purple — while the rendered pixels stayed grey. The rule now targets thesvgdirectly, and the verification reads the pixels:Same shape of mistake as the light-theme screenshot earlier today — checking the DOM instead of the frame — so it seemed worth naming rather than quietly fixing.
Verified
In the running app: twelve swatches offered, picking one tints that folder and no other, the colour survives a reload, and "Use the default colour" clears it.
npm run typecheck,npm test— 224 web + 88 server passing, including cases for the id-keyed lookup.🤖 Generated with Claude Code
Merged 2026-08-25 as coffey-labs/ihasmail@aad599d802
Rebuilt from: git history, session transcript.