Ollama support assumes localhost, ignoring config.toml

[roger-s-flores]

What version of Codex is running?

codex-cli 0.73.0

What subscription do you have?

Free

Which model were you using?

gpt-oss:20b

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Connecting to Ollama on another home (LAN) computer does not work at all.

~/.codex/config.toml:
oss_provider = "ollama"

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

[profiles.gpt-oss]
model_provider = "ollama"
model = "gpt-oss:20b"

run with
codex -p gpt-oss

Trying a command leads to five reconnection attempts followed by the error:
■ stream disconnected before completion: error sending request for url (http://localhost:11434/v1/chat/completions)

Note the ip address specified by base_url is replaced with localhost.

I don't think a remote base_url is supported. The tests in the rust code I see only use localhost.

I know the config.toml is read because if I change the line to
wire_api = "responses7"
I get the reasonable error that proves codex is reading config.toml:
Error: unknown variant responses7, expected responses or chat
in model_providers.ollama.wire_api

Ollama is running fine:
$ curl -i http://192.168.8.81:11434
HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Date: Thu, 18 Dec 2025 06:23:44 GMT
Content-Length: 17

Ollama is running

codex --oss similarly does not work. I was hoping the [model_providers.ollama] would be noticed and use the base_url specified because --oss is more convenient to type.
$ codex --oss
Error: OSS setup failed: No running Ollama server detected.

What steps can reproduce the bug?

Use ~/.codex/config.toml with a base_url that isn't localhost:
oss_provider = "ollama"

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

[profiles.gpt-oss]
model_provider = "ollama"
model = "gpt-oss:20b"

run codex:
codex -p gpt-oss

type any command that needs to connect to the remote ollama server

Notice five reconnection attempts followed by the message
■ stream disconnected before completion: error sending request for url (http://localhost:11434/v1/chat/completions)

What is the expected behavior?

The remote ollama server running at base_url should be connected to

Additional information

ollama version 0.13.4

[pd95]

I see this problem too... and I think I found a workaround: Do not use the name 'ollama' as your configuration for the model provider. It seems counterintuitive, but I have testet the following setup:

[model_providers.myollama]
name = "My Ollama"
base_url = "http://192.168.64.1:11434/v1"
wire_api = "responses"

[profiles.gpt-oss]
model_provider = "myollama"
model = "gpt-oss:20b"

And running codex -p gpt-oss will properly connect to the new Ollama "responses" API.

As I see it, the problem is that codex still enforces a fixed configuration if it detects that you want to run it with Ollama.
See line model_provider_info.rs below: based on the predefined names it uses a fixed kind of connection... "chat" API and localhost connection for Ollama.

codex/codex-rs/core/src/model_provider_info.rs

Lines 261 to 286 in a697408

	pub const LMSTUDIO_OSS_PROVIDER_ID: &str = "lmstudio";
	pub const OLLAMA_OSS_PROVIDER_ID: &str = "ollama";
	/// Built-in default provider list.
	pub fn built_in_model_providers() -> HashMap<String, ModelProviderInfo> {
	use ModelProviderInfo as P;
	// We do not want to be in the business of adjucating which third-party
	// providers are bundled with Codex CLI, so we only include the OpenAI and
	// open source ("oss") providers by default. Users are encouraged to add to
	// `model_providers` in config.toml to add their own providers.
	[
	("openai", P::create_openai_provider()),
	(
	OLLAMA_OSS_PROVIDER_ID,
	create_oss_provider(DEFAULT_OLLAMA_PORT, WireApi::Chat),
	),
	(
	LMSTUDIO_OSS_PROVIDER_ID,
	create_oss_provider(DEFAULT_LMSTUDIO_PORT, WireApi::Responses),
	),
	]
	.into_iter()
	.map(|(k, v)| (k.to_string(), v))
	.collect()
	}

This is not what you/we want. Therefore you have to create a custom model provider and not specifying one of the "reserved names" ollama or lmstudio to be able to override it.

Further you should not start codex using the --oss --local-provider ollama option. Otherwise you won't be able to apply a custom configuration.

I think this would make a great addition to the documentation!

Even better: how about supposing that Ollama knows about the responses API 😉

[roger-s-flores]

Philipp, this is a great workaround. I changed the name of my model provider from ollama to remote_ollama and reran codex. Codex now communicates with the remote ollama models as expected.

I agree that adding this workaround to config.md for people following it's instructions would be useful.

I saw a recent bug discussing Codex, Ollama and the responses API, and how Ollama now supports it. I do not see output chunked as described in bug #7600, although as you noted it could be because I'm using a custom config.

[neurostream]

@pd95 wow, this has been plaguing folks using remote ( remote, as in, on the same LAN, but not localhost ) ollama providers following the documented example in the codebase since > 0.58.0 ...I don't know how you discovered this, but thank you! I was about ready to give up on using codex as an agent driven by local inferrence. i tried this and it works with a different [model_providers.remoteollama] name ( NOT using "ollama" ]. back in business!