Ollama Now Lets Codex Desktop Run Local AI Models

Ollama has added an official integration for OpenAI’s Codex desktop app, giving developers a way to use models served by Ollama without abandoning Codex’s graphical coding workflow. The result combines a choice of local or cloud-hosted AI models with an app designed to inspect repositories, modify code, run commands, and review changes. Ollama’s Codex App documentation explains that the connection uses the company’s OpenAI-compatible endpoint.

That description is more precise than saying the main ChatGPT desktop app now has a universal Ollama model selector. The integration targets OpenAI’s Codex App, a desktop coding agent available for macOS and Windows. Ollama becomes its model provider, while Codex continues to supply the interface and software-development tools.

A source clarification is necessary. The official page currently lists Ollama v0.17.7 or later and Codex App 26.311.2136 or later as requirements. It does not substantiate the “Ollama 0.34” label, a five-model ChatGPT selector, or the specific GLM-5.3-Flash, DeepSeek-V4, Kimi-K3, Gemma 4, and Qwen 3.8 model names supplied with some descriptions of the update. The documentation uses Qwen3.5 as its local-model example, so the additional version and model claims should remain unconfirmed until Ollama publishes supporting release notes.

Ollama Replaces the Model, Not the Coding Workspace

The integration works by pointing Codex at Ollama’s local API rather than rebuilding Codex functionality inside the Ollama application. Ollama runs an HTTP server, normally at http://localhost:11434, and exposes an endpoint designed to accept a supported subset of OpenAI API requests.

Codex can therefore send model requests to Ollama using an interface it already understands. Ollama handles inference through a model running on the developer’s machine or through an Ollama Cloud model, then returns the response to Codex.

This separation matters because the model and the coding agent perform different jobs:

• Ollama loads the selected model and processes inference requests.
• The model generates plans, code, explanations, and tool instructions.
• Codex App manages the repository, displays diffs, runs workflows, and presents review tools.
• The operating environment controls file access, commands, Git repositories, and local development servers.

An OpenAI-compatible endpoint does not necessarily reproduce every behavior of OpenAI’s own models. Ollama’s compatibility documentation lists specific supported API features, including parts of the Responses API used by agentic applications. Model quality and tool-use reliability can also vary even when the API connection itself works correctly.

The useful development is therefore not merely that another chat window can run an open model. Developers can change the model provider while preserving a coding interface built around repositories, diffs, local servers, and iterative changes.

The Setup Takes One Command

Ollama has tried to keep the setup process out of configuration files. After installing the required applications, developers can launch the integration from a terminal:

ollama launch codex-app

According to the official instructions, Ollama configures the provider and opens Codex App automatically. The developer can then select an Ollama model from the app’s model selector.

The full process is:

1. Install Ollama from the official download page.
2. Install the Codex desktop application for macOS or Windows.
3. Run ollama launch codex-app.
4. Open a project in Codex.
5. Select an available Ollama model.

Local models must be downloaded before Codex can use them. The documentation provides Qwen3.5 as an example:

ollama pull qwen3.5
ollama launch codex-app

Ollama Cloud models do not require the complete model weights to be stored on the developer’s computer. Ollama can make the cloud model available when selected, although the user must be signed in and the inference request is processed remotely.

For developers who need more control, Ollama also documents a manual configuration method. Codex reads provider settings from ~/.codex/config.toml, where Ollama can be defined as a model provider using its local endpoint:

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

[profiles.ollama]
model = "qwen3.5"
model_provider = "ollama"

The profile can then be selected when starting Codex. This fallback is useful for debugging, maintaining multiple provider profiles, or changing the model without rerunning the automatic launcher.

Local and Cloud Models Solve Different Problems

A local model is the most interesting option for developers handling source code that should not be submitted to a remote inference service. When Ollama performs inference locally, prompts and model processing can remain on the machine running Ollama.

That does not make the entire Codex workflow automatically offline or private. Codex can open websites, interact with local servers, install dependencies, and use other network-connected tools. A repository may also contain build scripts or development services that communicate externally. Local inference reduces one important category of data exposure, but privacy still depends on the complete workflow.

Hardware presents the other tradeoff. Local models compete for system memory and compute resources with the code editor, compiler, containers, browser, and development server. Larger models may need quantization, shorter context settings, or more capable hardware to deliver acceptable latency.

Ollama Cloud addresses that limitation by running open models on hosted infrastructure. This gives Codex access to models that may be impractical to run on a laptop, but requests leave the local machine and depend on network availability.

The integration consequently supports a useful division of labor. A developer might use a smaller local model for private code exploration and routine edits, then switch to a cloud model for a more demanding refactor. The important question is not whether local or cloud AI is universally better. It is whether the selected model has enough coding ability, context capacity, speed, and tool reliability for the task.

The Desktop Tools Still Matter More Than the Chat Window

Codex App provides several workflow features that remain relevant when Ollama supplies the model. They are what distinguish the integration from sending coding questions to a general-purpose local chat interface.

The built-in browser can open a local development server or website inside Codex. Developers can annotate part of the rendered page and ask for a visual or behavioral change. The model receives a more specific request than “fix the layout,” while Codex connects that request to the working project.

In review mode, Codex presents code changes for inspection before they are accepted. Developers can comment on a diff, request corrections, and continue iterating without moving the discussion into another application.

Codex also supports Git worktrees, which create isolated copies of a repository for separate tasks. An agent can work in one tree without immediately altering the developer’s primary working directory. Isolation does not remove the need to inspect generated code, but it makes parallel experiments and rollback easier to manage.

These capabilities are app-level features. The selected model still affects how effectively Codex plans a change, interprets feedback, uses tools, and recovers from errors. A weaker model can technically connect to the app while struggling to complete a multi-file coding task reliably.

This Is Not Blanket ChatGPT Plugin Support

The official Ollama reference does not say that general ChatGPT plugins or apps such as Notion, Granola, Google Calendar, and GitHub automatically work with every Ollama model. It documents Codex’s built-in browser, review mode, worktrees, and model-provider configuration instead.

This distinction matters because an AI desktop workflow has several compatibility layers. The host application must expose a tool, the model must generate valid tool calls, the provider endpoint must carry those calls correctly, and the external service must authorize and execute them.

Changing the model backend does not guarantee that every ChatGPT integration will appear in Codex or behave identically. GitHub access through an opened repository is also different from a separate GitHub connector authenticated against the service’s API.

“Computer use” needs similar qualification. Codex can run development tasks, execute commands, work with files, and open sites in its built-in browser. That is not necessarily equivalent to a general computer-use agent with unrestricted control over arbitrary desktop applications.

Developers should evaluate specific tools rather than treating plugin compatibility as a single yes-or-no feature. The confirmed value here is access to Codex’s documented coding tools while an Ollama model handles inference.

What Ollama Changes for AI Coding

Local coding models have traditionally required developers to assemble separate components: a model runtime, command-line agent, editor extension, API configuration, and sometimes a custom permission system. The Codex integration reduces part of that setup by making Ollama a provider for an existing desktop agent.

It also makes model choice more visible. Developers can compare local and hosted models inside approximately the same workflow instead of changing applications for every test. That should make differences in instruction following, code review, latency, and tool use easier to observe.

The largest remaining uncertainty is not basic connectivity. It is whether individual open models can use Codex’s agentic workflow reliably across real repositories. Coding agents need more than code completion. They must inspect relevant files, avoid unnecessary changes, call tools correctly, interpret failures, and keep a multi-step task on track.

Model size alone will not answer that question. A smaller model with dependable tool behavior may be more useful for routine edits than a larger model that produces stronger code in isolation but handles an agent loop poorly. Independent testing across different repositories and hardware configurations will be more informative than a list of compatible model names.

Final Thoughts

Ollama’s Codex integration is important because it separates the desktop coding experience from a single model provider. Developers can retain Codex’s repository tools, reviews, browser annotations, and worktree isolation while deciding where inference runs.

The privacy benefit is real but bounded. Running a model locally can keep model prompts and source context off a hosted inference endpoint, yet browser activity, external services, dependencies, and other tools can still create network traffic. Teams working with sensitive code should audit the whole agent workflow rather than relying on the “local model” label.

The update should also be described accurately. Official evidence supports Ollama integration with the Codex desktop coding agent, not universal Ollama support across every ChatGPT desktop feature or plugin. Its success will depend on how consistently open models can perform multi-step coding work inside Codex, not simply whether they appear in a selector.