Understand what the port message means
A local runtime styling helper can use a Chrome DevTools Protocol endpoint bound to the loopback interface so it can identify and style the expected Codex renderer. A message that a port is occupied means another process already owns that address and number, or a previous recorded session has not closed. It does not prove malware, and it does not prove the occupant is safe to terminate. Development servers, browsers, test tools, or another helper instance can all use local ports. Record the exact message, requested port, launcher arguments, and whether the normal launcher was allowed to choose automatically before taking action.
- Copy the complete error text.
- Note automatic versus explicit port selection.
- Record whether Codex or a helper is already open.
- Do not infer process identity from the number alone.
Keep the debugging endpoint on loopback
The reviewed upstream description uses a loopback-only connection. Preserve that boundary. Do not change the address to all interfaces, forward the port through a router, expose it through a tunnel, or disable local firewall protections to make styling work. CDP is powerful because it can inspect and control the connected renderer. Other untrusted local software can also be a concern while the endpoint is active. Run only software you trust during the session, restore when finished, and verify that the recorded endpoint closes. A conflict should be resolved locally through correct process ownership and configuration, never by making the endpoint reachable from the network.
- Bind only to the documented loopback address.
- Do not tunnel or forward the endpoint.
- Avoid untrusted local software during the session.
- Restore and confirm closure afterward.
Identify the owning process before changing anything
Use the platform’s ordinary process and networking tools, or the project’s verify or doctor output, to identify which process is listening. Compare the process path, user account, start time, and parent process with applications you intentionally launched. Do not post the complete process list publicly because paths and arguments can contain personal information. If the owner is an unrelated development tool you need, close it normally or let the Dream Skin launcher choose a free port when that is its documented default. If the owner appears to be a stale recorded helper or themed Codex session, use the normal restore workflow rather than force-killing it first.
- Verify process path, user, and start time.
- Close known tools through their normal exit path.
- Prefer documented automatic free-port selection.
- Use restore for recorded theme sessions.
Remove unnecessary explicit port overrides
An explicit port is useful for controlled diagnosis but creates avoidable collisions in normal use. Review shortcuts, command history, environment configuration, or menu integrations for a manually supplied port. Remove the override only when the current upstream instructions say automatic selection is supported, then launch from a clean official-app state. Do not invent a random public-facing port or copy a number from another user’s issue. The helper and verification command must agree on the selected endpoint, so preserve diagnostic output that states which address was used. If an organization manages endpoint or firewall settings, follow that policy rather than bypassing it.
- Inspect shortcuts and launcher arguments.
- Use automatic selection where documented.
- Keep launch and verify configuration consistent.
- Respect managed-device network policy.
Distinguish stale state from an active conflict
A sudden conflict after a crash can indicate that a process survived while its visible window closed, or that saved state refers to a session that no longer matches reality. Save work, run documented restore, wait for normal process shutdown, and confirm official Codex opens cleanly. Avoid deleting state until the restore attempt has used it. Relaunch once and note whether the conflict repeats on the same port. A one-time stale session and a reproducible collision with another application require different fixes. Repeated conflicts should include the owner identity, launch order, and configuration source in an upstream report, with private path and account information removed.
- Restore before deleting state.
- Confirm official Codex after shutdown.
- Reproduce once from a clean state.
- Record owner and launch order if repeatable.
Define success and prepare a safe report
The conflict is resolved when the normal launcher selects an available loopback endpoint, the intended renderer is verified, the theme works on required surfaces, and restore closes the recorded session. Success is not simply suppressing the error while an unknown listener remains. For an unresolved issue, include operating system, architecture, source commit, exact sanitized error, whether the port was automatic or explicit, the identified process category, and restore result. Do not publish tokens, command arguments containing secrets, personal paths, task screenshots, or full process inventories. CodexSkin can correct this guide; the upstream project must investigate tool behavior.
- Available loopback endpoint selected.
- Expected renderer verified.
- Restore closes the recorded session.
- Sanitized, reproducible evidence ready if unresolved.