{"slug": "codex-cli-login-stuck-at-finish-signing-in-via-your-browser-a-managed-daemon-was", "title": "Codex CLI Login Stuck at \"Finish signing in via your browser\" — A Managed Daemon Was Holding Port 1455", "summary": "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.", "body_md": "# Codex CLI Login Stuck at \"Finish signing in via your browser\" — A Managed Daemon Was Holding Port 1455\n\n[Tadashi Shigeoka](https://codenote.net/en/author/tadashi-shigeoka/)· Sat, September 26, 2026\n\nI launched my usual [Codex CLI](https://developers.openai.com/codex/cli) and the TUI would not move past this screen:\n\nThe 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.\n\n## What I checked\n\nFirst, I confirmed whether the login itself had actually gone through.\n\n`~/.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.\n\nNext, I looked at who was bound to the OAuth callback port `localhost:1455`.\n\nThe 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).\n\nCodex 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.\n\n## Order I tried\n\nI tried the following top to bottom, and step 3 was the one that worked.\n\n### 1. Press Esc and relaunch `codex`\n\nSince 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.\n\n### 2. Device-code flow with `codex login --device-auth`\n\nI tried the device-code flow, which does not depend on a browser redirect.\n\nThe ChatGPT consent screen at `auth.openai.com/sign-in-with-chatgpt/codex/consent` then displayed this warning:\n\nEnable device-code sign-in for Codex, Excel, PowerPoint, and Word in your ChatGPT security settings, then run `codex login --device-auth` again.\n\nDevice-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.\n\n### 3. Kill the daemon holding port 1455, then `codex login`\n\nStop the resident process that owns the port, then run the normal OAuth login again.\n\nThe 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.\n\nWith 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.\n\n## A checking order for the same symptom\n\nThe problem is often the local state going stale rather than anything on the ChatGPT account, so this order is fast:\n\n1. Use `codex login status` and the timestamp on`~/.codex/auth.json` to confirm that credentials have been refreshed\n2. 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\n3. Press Esc and relaunch `codex` first\n4. 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\n5. Keep `codex login --device-auth` as a fallback only when you are willing to change ChatGPT’s device-code security setting\n\nThat’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.", "url": "https://wpnews.pro/news/codex-cli-login-stuck-at-finish-signing-in-via-your-browser-a-managed-daemon-was", "canonical_source": "https://codenote.net/en/posts/codex-cli-login-stuck-managed-daemon-port-1455/", "published_at": "2026-09-26 14:58:30+00:00", "updated_at": "2026-09-27 03:29:41.715341+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "ai-products"], "entities": ["Codex CLI", "OpenAI", "ChatGPT", "Tadashi Shigeoka", "codex app-server --managed-daemon", "VS Code"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/codex-cli-login-stuck-at-finish-signing-in-via-your-browser-a-managed-daemon-was", "markdown": "https://wpnews.pro/news/codex-cli-login-stuck-at-finish-signing-in-via-your-browser-a-managed-daemon-was.md", "text": "https://wpnews.pro/news/codex-cli-login-stuck-at-finish-signing-in-via-your-browser-a-managed-daemon-was.txt", "jsonld": "https://wpnews.pro/news/codex-cli-login-stuck-at-finish-signing-in-via-your-browser-a-managed-daemon-was.jsonld"}}