# Codex CLI Login Stuck at "Finish signing in via your browser" — A Managed Daemon Was Holding Port 1455 > Source: > Published: 2026-09-26 14:58:30+00:00 # Codex CLI Login Stuck at "Finish signing in via your browser" — A Managed Daemon Was Holding Port 1455 [Tadashi Shigeoka](https://codenote.net/en/author/tadashi-shigeoka/)· Sat, September 26, 2026 I launched my usual [Codex CLI](https://developers.openai.com/codex/cli) and the TUI would not move past this screen: The browser side had reached the [ChatGPT](https://chatgpt.com/) consent page and I had clicked “Continue,” but the TUI kept waiting. Here is how I traced the cause and what finally cleared it. ## What I checked First, I confirmed whether the login itself had actually gone through. `~/.codex/auth.json` had also been touched at 11:31 on the same day, so tokens were on disk. The OAuth exchange had completed; the TUI simply was not picking it up. Next, I looked at who was bound to the OAuth callback port `localhost:1455`. The listener was not the `codex` TUI I had open (PID 28816). It was an 18-hour-old background process, `codex app-server --managed-daemon` (PID 21226). Codex CLI is set up so that several clients (the TUI, the VS Code extension, the desktop app, and so on) can share the same authentication state through a resident `--managed-daemon` app-server. When an existing daemon is already bound to the OAuth redirect port, a later TUI cannot receive its own callback and the “Finish signing in via your browser” prompt never clears. ## Order I tried I tried the following top to bottom, and step 3 was the one that worked. ### 1. Press Esc and relaunch `codex` Since the credentials were already in place, restarting the TUI usually gets you into a normal session. This time it just returned me to the same waiting screen. ### 2. Device-code flow with `codex login --device-auth` I tried the device-code flow, which does not depend on a browser redirect. The ChatGPT consent screen at `auth.openai.com/sign-in-with-chatgpt/codex/consent` then displayed this warning: Enable device-code sign-in for Codex, Excel, PowerPoint, and Word in your ChatGPT security settings, then run `codex login --device-auth` again. Device-code sign-in requires an opt-in on the ChatGPT security settings side. I did not want to change that setting just to work around this login, so I stopped here. ### 3. Kill the daemon holding port 1455, then `codex login` Stop the resident process that owns the port, then run the normal OAuth login again. The PIDs to kill depend on your environment; check what is actually listening with `lsof -i :1455` before killing anything. If the Codex desktop app or a browser extension is sharing the same resident process, close those first. With the daemon gone, `codex login` let the newly started TUI itself bind `localhost:1455`, receive the browser’s OAuth redirect, and complete the sign-in. ## A checking order for the same symptom The problem is often the local state going stale rather than anything on the ChatGPT account, so this order is fast: 1. Use `codex login status` and the timestamp on`~/.codex/auth.json` to confirm that credentials have been refreshed 2. Use `lsof -i :1455` to see which process owns`localhost:1455` , and check whether a`codex app-server --managed-daemon` from an earlier session (rather than the TUI you just launched) is listening 3. Press Esc and relaunch `codex` first 4. If that does not clear it, kill the resident process and rerun `codex login` . If the Codex desktop app or a browser extension shares the same daemon, close those before killing it 5. Keep `codex login --device-auth` as a fallback only when you are willing to change ChatGPT’s device-code security setting That’s all from tracing the “Finish signing in via your browser” hang in Codex CLI to a stale `codex app-server --managed-daemon` holding `localhost:1455` and resolving it by killing the daemon and rerunning `codex login`, from the Gemba.