Most explanations of Codex skins stop at three words: "local CDP injection." That's true, but it hides the two things people actually get wrong — a skin is a fixed CSS engine driven by a few variables, not an AI that redraws your IDE, and there are concrete limits to what any skin can change. This page explains the real mechanism end to end, and then gives you the honest boundary: exactly what a Codex skin can restyle, and what it physically cannot. If a tool won't tell you the second part, you can't trust the first.
A Codex skin does not replace, repackage or fork the Codex app. Your real Codex keeps running; the skin is a cosmetic layer painted over it at runtime and peeled off on demand. Nothing you interact with is a screenshot — the sidebar, project picker, task content and composer stay the live Codex controls. The skin only changes how they look.
This is the actual sequence, and each stage is a checkpoint, not a formality:
Discover — locate the official Codex desktop app (com.openai.codex on macOS; the registered Microsoft Store package on Windows).
Validate — before attaching to anything, verify the app's code signature, Team ID, architecture and (on Mac) its bundled Node runtime. If these don't match, the process stops. You are not attaching a blind script to an arbitrary process.
Inject — launch Codex with a Chromium DevTools Protocol (CDP) endpoint bound to 127.0.0.1, connect only to the expected app:// renderer targets, and add CSS + a few decorative DOM elements above which the native controls still sit.
Watch — a small injector stays alive and re-applies the layer after reloads and route changes, so switching from Home to a Task doesn't drop your skin.
Here's the increment competitors don't tell you. The skin is not generated fresh by an AI each time. It's a single, human-authored stylesheet (dream-skin.css) that ships with the tool, plus a small set of variables the tool fills in:
| Variable | What you control |
|---|---|
--dream-skin-art | your image (banner + workspace background) |
--dream-skin-name | the greeting / theme name |
--dream-skin-tagline | the sub-line under the greeting |
--dream-skin-project-label | the "select project" label text |
| accent / surface / ink | your palette, via codex-theme-v1 fields |
When you "make a skin," you're not asking a model to paint an interface — you're feeding your image and text into a proven stylesheet's variables. That's why it's reliable and reversible: the CSS is fixed and tested; only your content changes. (It also means anyone claiming "our AI redesigns your whole Codex UI" is overselling — the layout comes from the fixed CSS, the personality comes from your image.)
diffAdded / diffRemoved / skill semantic colors.This is the part that builds trust, so we say it plainly:
The viral "full character takeover" screenshots you've seen get their richness from the uploaded artwork itself (a big, well-composed banner image) combined with this CSS — not from the tool repainting every control.
Codex is a web-tech desktop app; navigating routes or reloading can wipe injected styles. The injector watches for those events and re-applies, so your skin doesn't flicker away when you open a task. After a Codex version update, renderer internals may shift and you re-run the install — nothing was permanently patched, so this is a re-apply, not a repair.
codex-theme-v1 import — no injection, no engine, nothing to restore. Safest possible route.Understanding which mechanism you're using tells you exactly what you're trusting. Read the safety model →
No. It's a fixed, tested CSS engine driven by your image and a few text/color variables. The reliability comes from the CSS being fixed.
It can recolor/reshape backgrounds and add decoration, but it can't redraw the app's own SVG icons or move panels. It's appearance-only.
It styles renderer internals that can change when Codex updates. Re-running install re-applies it; nothing was permanently modified.
No — that's the native color import. A skin is a runtime-injected visual layer. Different mechanism, different capabilities.