Codex Local LLM Setup: Ollama, LM Studio, llama.cpp and vLLM (2026)

To run Codex on a local LLM, start Ollama or LM Studio and launch the CLI with codex --oss, which defaults to OpenAI's open-weight gpt-oss-20b, or add a provider to ~/.codex/config.toml for llama.cpp's llama-server or vLLM. Whatever the server, it must speak OpenAI's Responses API, because Codex no longer accepts Chat Completions providers, and the model needs reliable tool calling and at least 64K tokens of context.

Codex is OpenAI’s coding agent. The CLI is open source under Apache-2.0 in the openai/codex repository and runs on your machine; the IDE extension and the Codex mode of the ChatGPT desktop app share its configuration file. Local models work, but not on every surface, and not with every server that calls itself OpenAI-compatible.

Commands and keys below were checked on 4 November 2026 against Codex CLI 0.166.0, released on 29 October, OpenAI’s Codex documentation, the openai/codex source code, and the Codex pages of Ollama and LM Studio. Which model to run is a separate question, covered in our shortlist of open-weight coding models. The same exercise for other agents is in our Claude Code walkthrough for local models and our OpenCode configuration guide.

What works locally in Codex, and what does not

The CLI’s behaviour is confirmed in its source: the login screen appears only for providers that require OpenAI authentication, and the built-in Ollama and LM Studio providers do not. OpenAI’s authentication page also documents a no-authentication option for local custom providers, which leaves out env_key and every other credential setting.

A local model does not make Codex fully offline. Installation and the start-up update check need the network, and Codex sends anonymous usage metrics to OpenAI unless you switch them off. Web search is a hosted tool run by whichever provider receives the request; Ollama’s Codex page says searches sent through its profile go to Ollama’s search service, which needs ollama signin. /feedback uploads logs when you use it, and any MCP server you add makes its own connections. The switches for each are in the sandbox section below.

The Responses API requirement

Codex talks to model providers only through OpenAI’s Responses API. In the configuration reference, responses is the sole accepted value of wire_api, and an old wire_api = "chat" entry now stops Codex with an error telling you to switch. The retired ollama-chat provider fails the same way. OpenAI announced the deprecation in December 2025 and scheduled removal for February 2026, which is why older tutorials built on Chat Completions no longer work.

Codex with Ollama

First give the model room. Ollama chooses a default window from available VRAM, 4K tokens below 24 GiB and 32K up to 48 GiB, while its Codex page asks for at least 64K:

OLLAMA_CONTEXT_LENGTH=65536 ollama serve

The quickest setup is Ollama’s launcher, which refreshes Ollama’s model catalogue for Codex and starts it with a dedicated profile. Inside Codex, /model switches between your installed models that support tools; --config configures without starting and --restore removes the profile and catalogue again:

ollama launch codex

Without the launcher, the --oss flag connects a single run to Ollama. Codex defaults to gpt-oss:20b and pulls whatever model you name if it is missing:

codex --oss
codex --oss -m qwen3-coder:30b

Tags ending in -cloud, such as gpt-oss:120b-cloud, run on Ollama’s servers rather than yours. For a permanent setup, add oss_provider = "ollama" to ~/.codex/config.toml, or keep a profile file next to it. Since Codex 0.134.0, profiles live in their own files, ~/.codex/<name>.config.toml, selected with --profile <name>:

# ~/.codex/ollama.config.toml
model = "gpt-oss:20b"
model_provider = "ollama-local"
model_context_window = 65536

[model_providers.ollama-local]
name = "Ollama"
base_url = "http://localhost:11434/v1"
wire_api = "responses"

Start it with codex --profile ollama. Custom provider IDs must avoid reserved built-in names such as openai, ollama and lmstudio. Check the context the server actually loaded with ollama ps while Codex works.

Codex with LM Studio

LM Studio serves Codex through its /v1/responses route on port 1234:

lms server start --port 1234
lms get openai/gpt-oss-20b
lms load openai/gpt-oss-20b --context-length 65536
codex --oss --local-provider lmstudio

Without -m, Codex downloads openai/gpt-oss-20b through LM Studio if it is missing and loads it in the background. Pass -m with any model key LM Studio lists to use something else. LM Studio’s own guide recommends more than about 25K tokens of context; 64K leaves more room for tool output.

In config.toml, LM Studio can be set up two ways. oss_provider = "lmstudio" makes codex --oss choose LM Studio without asking, and a profile file pins a model:

# ~/.codex/lmstudio.config.toml
model = "qwen/qwen3-coder-30b"
model_provider = "lmstudio-local"
model_context_window = 65536

[model_providers.lmstudio-local]
name = "LM Studio"
base_url = "http://127.0.0.1:1234/v1"
wire_api = "responses"

We found no LM Studio documentation for the Codex mode of the ChatGPT desktop app as of 4 November 2026; Ollama’s integration, below, is the documented route there.

Codex with llama.cpp and vLLM through config.toml

Any other server is a custom provider. For llama.cpp, start llama-server with an explicit port, because current builds listen on 9931 by default, and an alias that becomes the model name:

llama-server -hf ggml-org/gpt-oss-20b-GGUF --alias gpt-oss-20b \
  --host 127.0.0.1 --port 8080 -c 65536 --jinja

Then describe it in ~/.codex/config.toml or a profile file:

model = "gpt-oss-20b"
model_provider = "llamacpp"
model_context_window = 65536

[model_providers.llamacpp]
name = "llama.cpp"
base_url = "http://127.0.0.1:8080/v1"
wire_api = "responses"

Keep model_context_window at or below the server’s -c value, so that Codex compacts history before the server runs out of room. For vLLM, use the same table with base_url = "http://127.0.0.1:8000/v1", and start the server with --enable-auto-tool-choice and the --tool-call-parser that matches your model, since tool calling is off by default. For several developers sharing one GPU server, our comparison of vLLM, Ollama and llama.cpp covers the trade-offs. The same provider table can also point at a gateway instead of a single server; our look at the OmniRoute gateway covers one open-source option.

Put provider settings in your user-level configuration. Codex ignores model_provider and model_providers in a project’s .codex/config.toml and prints a warning at start-up.

Local models in the Codex app and the VS Code extension

VS Code, Cursor and Windsurf

The Codex IDE extension keeps editor options under chatgpt.* settings but reads agent behaviour, including the model and provider, from the same config.toml as the CLI; Codex Settings → Open config.toml opens the file. Because --oss and --profile are command-line flags, put the provider table and the model, model_provider and model_context_window lines from one of the profiles above into the base file. That makes the local model the default for the CLI too.

On Windows, the chatgpt.runCodexInWindowsSubsystemForLinux setting runs Codex inside WSL2. If Ollama or LM Studio runs on the Windows side, localhost inside WSL2 does not reach it under the default NAT networking, so use the host’s address or Microsoft’s mirrored networking mode.

The Codex app in ChatGPT Desktop

Ollama documents the route for the desktop app. With Ollama 0.34.0 or newer, open the Ollama app, select Apps, switch ChatGPT (Desktop) on and follow the prompts, which may restart ChatGPT. Under Ollama’s Settings → Apps → ChatGPT you then choose up to five local or cloud models, and they appear in Codex’s model picker beside OpenAI’s.

Only requests made with an Ollama model go to Ollama. Chat and voice keep their usual ChatGPT connection, Codex still manages the sessions, and web search with an Ollama model uses Ollama’s search service, limited to three calls per response. Switching the integration off restores ChatGPT’s previous connection settings.

Choosing a local model for Codex

Codex’s own defaults point at OpenAI’s open-weight gpt-oss models. Both are Apache 2.0 mixture-of-experts models shipped in MXFP4, with a 128K window: gpt-oss-20b has 21B parameters with 3.6B active, and gpt-oss-120b has 117B with 5.1B active. Ollama’s library also lists Qwen models with tool support.

For models outside that guide, estimate memory the way our VRAM calculator does: weights equal parameters × bits ÷ 8, plus the KV cache for your context and runtime overhead. Our gpt-oss deployment guide works through those numbers for both sizes, and our Qwen3.8 hardware guide does the same for Qwen’s 27B model. For a broader comparison, including how well each model calls tools, use the coding-model shortlist linked above rather than raw parameter counts.

Context, tool calling and common errors

Codex sends a long system prompt and tool definitions with every turn, then file contents and command output, so a 4K or 8K window fills almost at once. Symptoms include tool calls that loop, half-finished edits and instructions the model seems to forget. Raise the server’s context first, then set model_context_window to match.

The errors you are most likely to meet:

• wire_api = "chat" is no longer supported. Change the provider to wire_api = "responses" and make sure the server has a /v1/responses route.
• ollama-chat is no longer supported. Replace it with ollama in model_provider, oss_provider or --local-provider.
• Ollama is too old. Codex’s version check names the minimum, Ollama 0.13.4; upgrade the server.
• does not support tools. Ollama refuses tool calls for models without tool support; pick a model whose library page lists tools.
• codex exec exits at once with --oss. Non-interactive runs do not prompt for a provider, so pass --local-provider or set oss_provider.
• A profile seems ignored. From Codex 0.134.0, --profile no longer reads [profiles.<name>] tables in config.toml; move the settings into ~/.codex/<name>.config.toml.

codex doctor --network-only, added in 0.166.0, checks configuration and connectivity when the server cannot be reached at all.

Sandbox, approvals and keeping code on the machine

The sandbox works the same with a local model as with OpenAI’s. In a Git repository Codex suggests its Auto preset, workspace-write with on-request approvals; outside version control it suggests read-only. In workspace-write, commands can edit the workspace but have no network access unless you enable it, and .git, .agents, .codex and .aws stay read-only. Enforcement comes from the operating system: Seatbelt on macOS, bubblewrap with seccomp on Linux and WSL2, and the MXC sandbox on Windows, with older elevated and unelevated implementations as fallbacks.

approval_policy now accepts on-request, never or a granular table; the old untrusted policy is retired. --dangerously-bypass-approvals-and-sandbox, alias --yolo, removes both layers and belongs only inside an environment that is already isolated. If bubblewrap cannot start inside a Docker container, OpenAI’s guidance is to make the container the boundary and run Codex with danger-full-access there. Our guide to isolating agents that execute code covers containers and microVMs.

To keep a local setup quiet on the network, add these keys to ~/.codex/config.toml:

web_search = "disabled"
check_for_update_on_startup = false

[analytics]
enabled = false

[feedback]
enabled = false

OpenTelemetry export is off unless you configure an exporter. Confirm the result with egress monitoring, because MCP servers and plugins have their own network behaviour.

Codex local vs Claude Code local vs OpenCode

Codex is the strictest of the three by default, and OpenAI documents its local route itself. Claude Code works locally only outside Anthropic’s support boundary. OpenCode accepts the widest range of servers but leaves isolation to you. For a smaller agent without approval prompts, see our Pi coding agent guide; for DeepSeek’s new browser-based harness, see our DeepSeek Harness guide. Our review of on-premises coding assistants compares the commercial options.

How VDF AI fits

VDF AI does not run or integrate with Codex. A local Codex setup keeps one developer’s code and prompts on one machine, but the model choice, approvals and network switches sit in a file that each developer controls, with no shared record of what the agent did.

VDF Code is VDF AI’s governed coding assistant for teams that need those decisions made centrally. It runs on infrastructure you control, including air-gapped sites, inside a platform with role-based access control on every plan and audit logs. For the model layer across the wider platform, VDF AI Router can register an on-premises vLLM or Ollama endpoint beside approved cloud models and, in air-gap mode, routes to local models only.