Codex Startup Hang: Check Provider Auth CWD

Ethan Park

Quick thanks to Jellypod for helping make this daily show a reality. Last time we told you to restart your background daemon after changing config in 0.163.0. Today is the flip side of that. A daemon that looks alive, accepts connections, and still never answers the one request your session needs.

Maya

The symptom is a CLI session stuck on "Waiting for startup," with no error at all. It comes from GitHub issue 55000, filed October 18, 2026. The reporter first saw it in a shared daemon session. Then they reproduced it on macOS arm64 with a freshly launched app server reporting 0.163.0, using an isolated temporary CODEX_HOME, no copied credentials, and no inference request. So this is a controlled repro, not just a hunch.

Ethan Park

Here's the path. At startup the client sends an account/read request. That calls read_account, which reloads configuration through load_latest_config with no project. 0.163.0 changed that reload to use a non project configuration with a stable Codex home fallback, so the general case was fixed. An earlier issue, 54408, was closed on that basis. But there's a leftover. Each command backed provider auth table has a cwd field, and when you omit it, a function called default_provider_auth_cwd fills it in. That function falls back to the process's current directory, and if it can't get one, it panics. The exact message is: provider auth cwd must resolve, no such file or directory, os error 2.

Maya

And the part that makes this nasty is that the provider doesn't have to be in use. The reporter's config had a provider called repro, with a base URL and an auth table containing just a command. No model_provider line selecting it. The default OpenAI provider stayed selected. They ran three controls. With no provider definition, account/read worked before and after deleting the server's startup directory. With the unused provider and no auth cwd, it worked before deletion, then after deletion got no response within five seconds. Same provider with cwd set to slash in its auth table, it worked both times.

Ethan Park

So the failure happens when the config is deserialized, before any question of which provider you're using. One detail worth being precise about. The server process stayed alive. The request just never got a response, and stderr showed the panic at config_types.rs, line 629. That would explain why the client has nothing to show you, though the report doesn't spell out how the dropped request turns into a hang, so treat that last step as our reading. Also, the reporter deleted an empty temporary startup directory. If your daemon was launched from a scratch folder you later cleaned up, that's the same shape, but that's our inference, not something the issue claims.

Maya

So what do you do today. First, check your config.toml for any model providers entry that has an auth table with a command, and add an explicit cwd to each one. The reporter's test used slash, and that restored success. But they also note that the right directory depends on what your auth command actually needs, so pick something durable that makes sense for your helper. A stable path under your Codex home is a reasonable shape. If you're already hung, the reporter's recovery was to run codex with the no daemon flag, or to stop the daemon and start a new session from a directory that still exists. And since a running daemon only loads config when it deserializes it, remember our restart advice from last time after you edit.

Ethan Park

Caveats. As of the report, the issue is open, labeled a bug, with nobody assigned, and it's one reporter's reproduction, repeated in a second run. The expected behavior they describe is that an omitted auth cwd should resolve against a valid base or return a handled error, not panic. So an explicit cwd is a workaround, not a confirmed permanent answer. Also, the no daemon flag only gets you out of this particular trap. It doesn't change what's in your config.

Maya

A few smaller things from this week. Issue 54816 reports that in 0.164.0 alpha 3, which is a prerelease, typing right after launch can stall echo and redraw. Session attachment triggers a second skills refresh, and the main event loop awaits that request inline, so terminal input waits for it. The reporter delayed that response six seconds on purpose to expose it, so don't read six seconds as a normal delay. Next, issue 54738, on WSL2 with 0.163.0: resuming with the no daemon flag can show "This conversation is open in another app," when the owner is actually Codex's own shared daemon holding an idle writer lock. The reporter's workaround was codex no daemon fork with the thread ID, which continues in a new thread rather than restoring the original. And one genuine improvement in the 0.163.0 notes: you can return to an existing side conversation with /side after switching threads, and answers to pending prompts go back to the thread that asked.

Ethan Park

If you only do one thing after this episode, open your config and look for provider auth tables without a cwd. It takes a minute, and it's the difference between a clear error and a session that just sits there waiting.