Browser tools
Create, preview, and structurally validate selected files locally. The site does not apply a theme to Codex.
Know which layer handles the files, what Structural PASS does not prove, and when to stop before or during local Engine use.
Create, preview, and structurally validate selected files locally. The site does not apply a theme to Codex.
An independent process uses a loopback CDP endpoint. Keep the endpoint on a trusted local machine.
Stop for FAIL, CANNOT_VERIFY, mismatched hashes, unexpected files, platform mismatch, or incomplete recovery.
CodexSkin Tools creates, previews, and structurally validates Enhanced theme files in the browser. Selected image and theme JSON files are not uploaded under the current True MVP contract. The website does not directly control Codex and does not execute user-provided packages.
Applying an Enhanced theme requires the independent Codex Dream Skin local Engine. The Engine launches or connects to Codex through a loopback Chrome DevTools Protocol endpoint and injects CSS or DOM into the local renderer. The loopback debug endpoint does not provide user-level authentication. Use it only on a trusted local machine and close the themed session through Restore when finished.
Save work and close or back up important sessions. Use only a named theme directory containing one theme JSON and one referenced PNG, JPEG, or WebP image. Review the theme source, hashes, Runtime status, and exact platform and build evidence. Do not apply files that FAIL validation or contain scripts, executable content, nested archives, path traversal, or unexpected files.
PASS means known structural checks passed. It does not establish runtime compatibility, absence of malicious behavior, system safety, certification, or OpenAI support. Missing parser, metadata, hashing, counterpart file, or target-build evidence must produce CANNOT_VERIFY or NOT_VERIFIED. WARN requires review, and FAIL identifies a blocking structural result.
Follow the platform-specific Apply, Verify, and Restore guide for the pinned Runtime SHA. A restore claim requires evidence that injected content was removed, the themed CDP session and port were closed, and stock Codex reopened without debug flags. If the current Codex build differs from the tested build, show REVERIFY_REQUIRED or NOT_VERIFIED.
Runtime evidence is limited to the exact OS and architecture, Codex build, Engine version, Runtime SHA, artifact hash, date, evidence hash, and recovery record shown. REFERENCE_ONLY is not a CodexSkin formal verification. SHA-256 values support integrity comparison; they are not digital signatures, identity proof, malware review, or safety certification.
Stop when validation FAILS, a required check returns CANNOT_VERIFY, rights or redistribution is blocked, a hash differs, package contents are unexpected, or the platform guide does not match. During Restore, keep checking until the injected content, themed process, debug port, and stock reopen are all accounted for. Do not turn an incomplete check into a positive state.
CodexSkin Tools is an independent project and is not affiliated with, endorsed by, or sponsored by OpenAI.
Treat the themed session as a temporary local operation. Confirm that the Engine guidance names the intended loopback address and pinned Runtime SHA before starting. Do not forward, proxy, or expose the debug port to another device or network. Keep unrelated browser and Codex sessions separate so the user can identify which process belongs to the themed run. When the task is finished, use the documented Restore flow and check the process and port instead of assuming that closing a visible window ended the local session.
An unavailable check is information, not a neutral pass. If image metadata cannot be decoded, a counterpart file is missing, hashing cannot run, or the target build has no evidence, keep CANNOT_VERIFY or NOT_VERIFIED next to the affected item. Explain what input or capability is missing and what the user can provide or review next. Do not average completed checks into a score that hides a blocking FAIL or an unavailable security-relevant check.
A useful recovery record identifies the same operating system, architecture, Codex build, Engine version, Runtime SHA, and artifact that were used for Apply. It records removal of injected content, closure of the themed CDP session and loopback port, and reopening of stock Codex without debug flags. If the user can confirm only part of that sequence, show the completed observations and label the remaining recovery result CANNOT_VERIFY. This keeps a partial observation from becoming a general restore claim.
No. PASS reports known structural checks only; it does not establish runtime behavior, absence of malicious behavior, system safety, certification, or platform support.
The independent Engine launches or connects to Codex through a local Chrome DevTools Protocol endpoint to inject CSS or DOM into the local renderer. The endpoint lacks user-level authentication and should remain on a trusted local machine.
The record must show that injected content was removed, the themed CDP session and port were closed, and stock Codex reopened without debug flags.