Codex CLI not working: the sandbox is usually why

codex doctor. As of August 2026 it checks runtime, authentication, network reachability for the provider you are actually using, terminal environment, configuration, Git state, and MCP servers in one command, and codex doctor --json produces a redacted report you can attach to a bug report.

Because workspace-write disables outbound network access by default. Set network_access = true under [sandbox_workspace_write] in config.toml when you need it, or pass it for one run with codex -c sandbox_workspace_write.network_access=true.

The sandbox is probably read-only. Run with --sandbox workspace-write, or set sandbox_mode in config.toml. If it can write inside the project but not outside, that is workspace-write working correctly; add the path to writable_roots rather than removing the sandbox.

Run once with --sandbox danger-full-access --ask-for-approval never. If the failure disappears, it was policy rather than a defect. Then fix the configuration narrowly instead of staying without a boundary.

The session is authenticated with an API key rather than your ChatGPT sign-in, and OpenAI bills API key usage through your Platform account at standard API rates. Run codex login status to see the active method, then codex logout and codex login to sign in with ChatGPT. To pin a machine to one rail, set forced_login_method to chatgpt in config.toml.

Use codex login --device-auth, which completes the flow on another device. Alternatively pipe a key in with printenv OPENAI_API_KEY | codex login --with-api-key, or copy ~/.codex/auth.json from an already authenticated machine and treat it like a password.

Yes. In PowerShell it uses the native Windows sandbox, and in WSL2 it uses the Linux implementation, which needs bubblewrap installed inside the distribution. Codex prints a startup warning when it cannot enforce the sandbox, and that warning is worth reading rather than dismissing.

log_dir defaults to $CODEX_HOME/log, and setting it explicitly also turns on the opt-in plaintext TUI log. Start with codex -c log_dir=./.codex-log and tail ./.codex-log/codex-tui.log. Non-interactive codex exec prints its messages inline instead, and honours RUST_LOG.

Four different failures show the same spinner. The model may genuinely be thinking, which on high reasoning effort takes minutes with no output. The response stream may have dropped, which you can tell from a Reconnecting counter followed by "Stream disconnected before completion". An MCP server may have missed its 10 second startup handshake, which hangs the session before the first token. Or a sandboxed child may be wedged, in which case the stop button does nothing and the state survives a restart.

Press Esc first. It interrupts the current turn and leaves the session alive, so you keep the conversation and can steer it elsewhere. Ctrl+C exits Codex outright, which is what you want only once the turn has stopped. If you do exit, codex resume reopens a recent chat from the current repository.

Yes. Each server gets 10 seconds to complete the initialize handshake, and a cold npx that has to reach the registry and download a package routinely misses it, especially on Windows where every new file passes the real-time scanner. Raise startup_timeout_sec under [mcp_servers.<id>] in config.toml. The per-tool timeout is separate and defaults to 60 seconds via tool_timeout_sec.

request_max_retries, stream_max_retries, and stream_idle_timeout_ms tune it, with defaults of 4, 5, and 300000 milliseconds. They are only valid inside a [model_providers.<id>] block, and the built-in openai provider is reserved, so you cannot raise them for the default sign-in. Setting them at the root of config.toml appears to work and changes nothing.