Codex CLI with local models: --oss, Ollama and LM Studio

Run codex --oss and Codex CLI talks to a model on your own computer through Ollama or LM Studio instead of OpenAI's servers. Choose the server with --local-provider ollama (or lmstudio), or set oss_provider once in ~/.codex/config.toml. Choose the model with -m. Without -m, Codex uses gpt-oss:20b on Ollama and openai/gpt-oss-20b on LM Studio.

Every flag and key below comes from OpenAI's CLI reference and config reference, and from the Codex source on GitHub where the docs are silent, all read on 24 October 2026 (Codex rust-v0.164.0). We checked them on the day because older third-party guides disagree with today's Codex, mostly on wire_api.

Codex CLI with Ollama in four steps#

1. Install Ollama and make sure it is running. It listens on 127.0.0.1:11434 by default.
2. Give it room for Codex's prompts. Ollama's Codex page asks for a context window of at least 64k tokens, and Ollama only gives 4k by default on a machine with under 24 GiB of VRAM. Start the server with OLLAMA_CONTEXT_LENGTH=64000 ollama serve, or move the context slider in the Ollama app's settings. ollama ps then shows, under PROCESSOR, whether the model still fits on the GPU.
3. In your project, run codex --oss --local-provider ollama. Codex checks the server, refuses an Ollama older than 0.13.4 ("Codex requires Ollama 0.13.4 or newer"), and pulls gpt-oss:20b if it isn't there yet.
4. For another model, add -m: codex --oss --local-provider ollama -m gpt-oss:120b. The name is the one ollama list shows.

Ollama also ships its own launcher: ollama launch codex starts Codex with a dedicated Ollama profile, and ollama launch codex --restore removes it again. Ollama's Codex page also shows the manual route, a profile file at ~/.codex/ollama-launch.config.toml loaded with codex --profile ollama-launch.

How Codex picks the local provider#

--oss means "use a local open source model provider". Which one depends on three things, in this order:

1. --local-provider ollama or --local-provider lmstudio on the command line, for this run.
2. oss_provider = "ollama" or oss_provider = "lmstudio" in ~/.codex/config.toml.
3. Neither set: the interactive codex asks you to choose between LM Studio and Ollama.

codex exec differs on the third point. With --oss and no provider from the flag or the config, it exits with an error instead of asking. Set oss_provider once and both commands behave the same.

-m (or --model) overrides the model for the run, as it does with OpenAI's own models. Leave it out and Codex falls back to the default for that provider. Either way, Codex downloads the model first if the server doesn't have it. That happens only under --oss: in Codex's source the readiness check and the pull sit behind the flag.

Ollama vs LM Studio for Codex: setup side by side#

Both run through the OpenAI Responses API (POST /v1/responses). The example models are the ones each vendor's own Codex page uses (Ollama, LM Studio), not our picks.

One Ollama detail: its Codex page also shows gpt-oss:120b-cloud. Cloud models run in Ollama's cloud, not on your machine (Ollama Cloud docs), so pick one only if sending the code there is fine with you.

Codex local model settings in config.toml#

The keys live in your own ~/.codex/config.toml. Codex ignores model_provider and model_providers in a project's .codex/config.toml, so a provider set inside a repository has no effect. Where each file sits and which one wins is in our Codex config.toml guide.

The smallest local setup is one line, which makes plain codex --oss work without the flag:

oss_provider = "ollama" # or "lmstudio"

To keep a local setup apart from your usual one, use a profile. Since Codex 0.134.0 a profile is its own file, ~/.codex/<name>.config.toml, loaded with codex --profile <name>; a [profiles.<name>] table inside config.toml is no longer read. A local profile can be as short as this:

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

ollama and lmstudio are built-in provider ids, so model_provider can name them directly. Without --oss, though, Codex doesn't check the server or pull the model, so run ollama pull gpt-oss:20b first.

A custom provider: Ollama on another machine#

For a server that isn't on localhost, such as a desktop with a big GPU, define your own provider. The id can't be openai, ollama or lmstudio: those are reserved.

model_provider = "gpu_box"
model = "gpt-oss:120b"

[model_providers.gpu_box]
name = "Ollama on gpu-box"
base_url = "http://gpu-box:11434/v1"
wire_api = "responses"

For a local server, name, base_url and wire_api are enough. For a server that wants a key, env_key names the environment variable that holds it. OpenAI's reference lists more provider keys, for extra headers, query parameters, retries and timeouts. For wire_api it allows one value, responses, which is also the default when you leave the line out.

On the other machine, Ollama has to listen beyond itself. It binds 127.0.0.1 until you set OLLAMA_HOST: on a Mac running the Ollama app, launchctl setenv OLLAMA_HOST "0.0.0.0:11434" and restart the app (Ollama FAQ). Codex's source also reads CODEX_OSS_BASE_URL and CODEX_OSS_PORT for the built-in local providers, but a comment there calls them experimental, so we'd use the provider table.

Errors you may hit#

`wire_api = "chat"` is no longer supported. Codex removed the Chat Completions wire, and many guides written before that still show wire_api = "chat". Change it to "responses" or delete the line, and make sure the server answers /v1/responses. Codex's error links discussion #7782.

`ollama-chat` is no longer supported. The same change for the old provider id: replace ollama-chat with ollama in model_provider, oss_provider or --local-provider.

Ollama <version> is too old. Codex requires Ollama 0.13.4 or newer. Update Ollama. The check exists because older servers don't speak the Responses API.

codex exec --oss stops with an error before doing anything. No provider was set. Add --local-provider ollama or set oss_provider.

What local models handle in Codex, and what they don't#

We haven't benchmarked open models in Codex and won't quote anyone else's numbers here. What the vendors' own pages and Codex's design tell you is enough to set expectations.

Codex is an agent: every turn sends its instructions, the tool definitions and whatever files it has read, then waits for the model to call tools in the right format. That is why Ollama asks for 64k of context and LM Studio for more than 25k. A model squeezed into 4k will lose the start of its own conversation. Tool calling also varies between open models; some follow the format closely, others drift. Speed depends on your hardware, and a model that barely fits in memory makes a slow agent.

Local models suit small, contained jobs: renames, tests for one function, docstrings, a script you can check at a glance. They also suit code you'd rather not send anywhere, and trying an open model on your own repository. Long refactors across many files and slow debugging sessions are where a frontier model is still worth paying for. If you're weighing the agents themselves rather than the model behind them, our Claude Code vs Codex comparison covers that. Claude Code reaches Ollama a different way, through Ollama's Anthropic-compatible API, and the steps are in Claude Code with Ollama.

How Shuriken does it#

Shuriken is a harness that runs Codex, Claude Code and other agents on your computers. From 5.1, a local model can be a source for Codex: in Shuriken, open Sources › Add source, pick Codex, then Custom endpoint. Under "On this computer", choose Ollama or LM Studio and the address fills itself in (http://localhost:11434 or http://localhost:1234/v1). Press Test; "Reached · 3 models" (with however many it serves) means it answered. A model on this computer or your local network needs no key.

Shuriken then starts each Codex chat on that source with a provider entry of its own: the address with /v1 added when it's missing, on the Responses API. It passes that to Codex when the chat starts, so your ~/.codex/config.toml stays as you wrote it.

A local source never goes ahead of your subscriptions. Choose Use on it and your Codex chats run there. Otherwise, once every ChatGPT sign-in and key you added for Codex is out, source switching can move a running Codex chat onto it between turns, if the chat's history can be read there. The local models page has the rest, including how Claude Code does the same. Download Shuriken to try it with the server you already run.