I made a set of 50 free dark themes for Claude Code. The source, install instructions and all 50 theme files are here:
https://github.com/notgabriels-sys/claude-code-50-dark-themes
This started as a small personal project. I wanted Claude Code to feel more comfortable during long sessions, but I did not want themes that only looked good as color swatches and then made real terminal states harder to read.
After making the set, the useful lesson was simple:
dark themes are not just background colors.
The main design choice: do not repaint every semantic color
A lot of dark palettes look fine as static color cards, but developer tools need meaning. A warning, an error, a success state, a diff addition and a diff deletion should not collapse into the same decorative accent.
The important implementation detail in this project is that every theme inherits Claude Code's base dark preset and overrides only a controlled set of interface roles. The success, error, warning and diff colors are intentionally left to the base preset, so they keep their semantic green, red and yellow meanings.
Here is an abbreviated version of amber-room.json:
{
"name": "Amber Room",
"base": "dark",
"overrides": {
"claude": "#E0A83C",
"text": "#EDEBE8",
"inactive": "#AFA79D",
"subtle": "#342F27",
"promptBorder": "#E0A83C",
"userMessageBackground": "#2C2821"
}
}
That limited override surface is deliberate. It lets the visual identity change without turning status colors into decoration.
The roles I kept checking were:
- errors should still feel like errors
- warnings should remain visually distinct from errors
- success states should not look like generic decoration
- diff additions and deletions need enough contrast from each other
- muted text should be readable but not compete with primary output
- the background should support long sessions, not dominate them
Contrast hierarchy matters more than vibe
The difficult part was usually not choosing a hue. It was keeping the hierarchy readable across primary text, inactive text, subtle surfaces, prompt borders and raised user-message backgrounds.
The safer combinations had:
- a calm dark surface
- foreground text that stayed readable
- muted text that did not disappear
- accents that worked in small UI labels, not only in big preview blocks
The funny part is that the “loudest” palettes often became less useful than the restrained ones.
Terminal background matters
Claude Code cannot set the terminal application's background color, so that remains a separate terminal setting. For the full effect, I set the terminal background to each theme's surface hex.
Without that, the palette can still work, but the theme does not feel fully integrated. The background is not just decoration; it is part of the reading environment.
That is also why the repository documents the matching surface value. A theme is not only a few accent swatches; it is a working space.
The install path had to stay boring
For a visual project, the temptation is to spend all the effort on the gallery. But the install flow matters more.
The project supports the native Claude Code plugin marketplace flow:
claude plugin marketplace add notgabriels-sys/claude-code-50-dark-themes
claude plugin install 50-dark-themes@notgabriels-themes
The README also keeps a manual copy-to-~/.claude/themes/ path visible. That matters because a theme pack is only useful if someone can install it without guessing.
The basic lesson: if the thing is free and practical, the path to use it should be practical too.
I kept the themes free
The 50 Claude Code themes are free and MIT licensed.
If you use Claude Code and care about readable dark UI, I would genuinely like feedback:
- Which themes feel comfortable for long sessions?
- Which ones look good but fail in real use?
- What semantic color roles should be improved?
- Are there terminal/editor combinations where the contrast breaks?
Here are the complete theme list, source files and install instructions:
https://github.com/notgabriels-sys/claude-code-50-dark-themes
Disclosure: I used AI assistance to structure and edit this article. I reviewed the technical claims, example configuration and links against the public repository before publishing.

Top comments (0)