Codex CLI Login Stuck at "Finish signing in via your browser" — A Managed Daemon Was Holding Port 1455

A Codex CLI login hang at the "Finish signing in via your browser" prompt was traced to an 18-hour-old `codex app-server --managed-daemon` process (PID 21226) holding the OAuth callback port localhost:1455, according to a first-person account by Tadashi Shigeoka published September 26, 2026. Because Codex CLI shares authentication state across clients through a resident managed daemon, the newly launched TUI (PID 28816) could not receive its own OAuth redirect even though tokens had already been written to ~/.codex/auth.json at 11:31. Killing the daemon and rerunning `codex login` let the new TUI bind localhost:1455 and complete sign-in; the device-code fallback `codex login --device-auth` was abandoned because it requires enabling device-code sign-in in ChatGPT security settings.

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.