Are Codex skins safe? The honest security model

The one real tradeoff: the local CDP port

To style Codex at runtime, the skin launches it with a Chromium DevTools Protocol (CDP) endpoint on 127.0.0.1. Two facts, both true:

• Good: loopback means it is not exposed to your network — other devices on your Wi-Fi can't reach it.
• The catch: CDP has no same-user authentication. Any other software already running under your own user account could, in principle, connect to that port while it's open.

That's the entire security story in one paragraph. Everything else is how you manage it.

Threat model, plainly stated

Who is the risk, and who isn't?

• Not a risk: someone on your network, a website you visit, or the skin site itself — none of them can reach a loopback CDP port.
• The actual risk: malware or untrusted software you've already run on the same machine, while a themed session is active. If your machine is already compromised, an open CDP port is one more surface. If it isn't, the exposure window is small and under your control.
• Mitigation you control: don't run sketchy local programs during a themed session, and Restore when you're done to close the port.

This is the same tradeoff any CDP-based devtool has. We state it because a tool that hides it is the one to worry about.

What the skin cannot reach (and why, technically)

A skin is a CSS + DOM cosmetic layer in the renderer. That has real, structural consequences:

• API keys, Base URL, model provider settings live in Codex's config and process — outside the styling layer. The skin engine reads none of them; theming and API configuration are deliberately separate concerns. This isn't only a promise — a stylesheet has no reason or pathway to touch config.toml credentials.
• Your conversations, projects and task content are Codex data. The skin paints over the surface; it doesn't exfiltrate content. Nothing is uploaded — image processing and packaging happen in your browser, not on a server.
• The skin site never reaches your computer. You download a pack and run it locally; the website is not a remote controller.

What it never modifies on disk

The engine uses runtime injection, not file patching. It does not:

• replace or edit the macOS .app bundle or app.asar,
• alter the Windows WindowsApps package,
• rewrite the official code signature.

Because nothing on disk is patched, removal is complete and clean — there's no modified binary left behind.

Why Restore is a security control (not optional)

Treat Restore as the action that closes the exposure window, not just a way to get the plain look back. Running Restore:

1. stops the injector,

2. closes the local CDP debugging session (shuts the port),

3. restores your saved appearance settings,

4. reopens Codex clean.

So "Restore when you no longer need the skin" is literally "close the debugging port when you're done." Make it a habit, especially on shared or work machines.

How to verify what you downloaded

Trust, but verify:

• Download only from the official source — never a repackaged third-party mirror (repackaged installers are the classic supply-chain risk).
• If a SHA-256 checksum is published for the pack, confirm it matches what you downloaded. A checksum proves the file is the exact one published — it proves identity, not safety, so still read the prerequisites.
• Never put API keys, auth files, or private screenshots inside a theme/skin package you share.

Safe-use checklist

• ✅ Launch official Codex once before installing.
• ✅ Download only from the official source; verify checksum if provided.
• ✅ Don't run untrusted local software during a themed session.
• ✅ Run Verify after install; run Restore when finished.
• ✅ Keep theming and API config separate — never bundle credentials.

FAQ