Local LLMs in the Codex App: OpenCodex Setup and Privacy Limits
Tech GuruThe interesting part of running a local model in a coding assistant is not the model picker. It is knowing which program receives your prompt, which program can run tools, and whether a feature silently sends data to a hosted service. A recent XDA article highlights OpenCodex. The important naming correction is that OpenCodex documents integration with the Codex desktop app and CLI. That is not a general switch that makes the ordinary ChatGPT desktop chat app run an arbitrary local model.
Quick Answer
If you only need the Codex CLI, try its documented --oss mode with Ollama or LM Studio first. If you specifically want local models in the Codex desktop app's model picker, OpenCodex is a third-party proxy that can route the app to Ollama. Keep the proxy and model server on loopback, select an explicitly local model, disable hosted sidecars and fallback routes, and test the path with harmless prompts. A local model alone does not prove an offline or private workflow.
What Is Actually Running?
| Component | Job | Trust question |
|---|---|---|
| Codex app or CLI | Reads your task, offers tools, applies edits when authorized | What files and commands may this client access? |
| OpenCodex | Translates and routes requests between Codex and model providers | Which provider and sidecars are configured for this turn? |
| Ollama | Serves the downloaded model on 127.0.0.1:11434 by default |
Is the selected model local rather than a cloud model? |
| Optional web/vision service | Supplies search or image descriptions to a model that cannot do them | Does a prompt, image, or search query leave the device? |
The data path for the setup below is Codex app -> OpenCodex on 127.0.0.1:10100 -> Ollama on 127.0.0.1:11434 -> downloaded model. OpenCodex's own documentation says it edits the user-level Codex configuration and model catalog to wire this up. It also supports hosted providers and sidecars. Do not infer the active destination from the word "local" in a menu label; verify it in the proxy configuration and request log.
Normal text task: what should remain local?
The prompt follows the selected local provider to Ollama. Confirm the provider in OpenCodex's request log and the model in Ollama; the diagram is a target design, not captured test evidence.
Search or image task: where can it branch?
An enabled search or vision sidecar may send a query or image to a hosted backend. Disable those features for an offline claim and verify the failure behavior.
Local model unavailable: what should happen?
The task should fail visibly rather than route to an unapproved cloud provider. Test this in a scratch profile before allowing sensitive prompts.
Decide Whether You Need a Proxy
The least complicated path is not always the one in the headline. OpenAI documents native local-provider support for the Codex CLI through --oss; it can select Ollama or LM Studio. That is worth trying before installing a third-party process with access to your coding workflow. OpenCodex adds value when you need its Codex app model catalog, protocol translation, or routing across multiple backends. Those features also add a configuration and trust boundary.
Start with a disposable repository and no private data. The steps that follow are documentation-backed, not a TechGeeks lab result. We have not independently verified a current Codex/OpenCodex/Ollama version matrix or captured an egress trace. Use the acceptance checks below to establish what works in your own environment before trusting it with sensitive code.
Before You Start: Safe Defaults
You need a supported Codex installation, Ollama, enough memory for your chosen model and context, and (for the proxy path) Node.js 18 or newer. Confirm current installation instructions on the vendor pages. Do not run an unreviewed installer or proxy under an administrator account merely to avoid a permissions problem.
Use a non-sensitive scratch project. Do not grant unattended shell execution, broad filesystem access, or repository write access for the first test. Keep both services bound to loopback. If you already use Codex, back up $CODEX_HOME/config.toml (normally ~/.codex/config.toml) and record any existing custom provider settings before OpenCodex changes them. Do not copy auth.json, tokens, or configuration backups into the repository you are testing.
For a small smoke test, Ollama lists qwen2.5-coder:7b as an available 7B coding model with a roughly 4.7 GB download. That file size is not a RAM or VRAM sizing guarantee. A larger coding model may perform better on real agent tasks, but only if your hardware can run it with a useful context window. Check the model license and exact tag before deploying it for work.
ollama --version
ollama pull qwen2.5-coder:7b
ollama list
curl --fail --silent http://127.0.0.1:11434/api/tags
The last request should return JSON with a models list containing the downloaded model. That is an expected check, not output observed by TechGeeks. If it fails, fix Ollama first; a proxy cannot rescue a model server that is not responding. If the model is too large for your machine, choose a smaller verified tag, record it, and avoid equating a successful one-sentence response with coding competence.
Path A: Try the Native Codex CLI First
OpenAI's advanced-configuration documentation describes --oss for local providers. In a scratch repository, launch the CLI with Ollama selected:
codex --oss --local-provider ollama --sandbox read-only --ask-for-approval on-request
Select an installed model if the client prompts. Ask it to explain a harmless file without editing anything. Keep the sandbox read-only and approvals enabled under your normal Codex policy. If you use a non-interactive codex exec workflow, set a local provider explicitly: OpenAI documents that it otherwise exits rather than prompting.
If this meets your need, stop here. You have one less network-facing process and one less component that can alter Codex configuration. It does not establish that every Codex feature is offline; use the egress checks below and audit every optional tool separately.
Path B: Add OpenCodex for the Desktop App
OpenCodex is an independent community project, not an OpenAI product. Read its installation guide and Codex integration guide before giving it access to your local workflow or account. Review its package, permissions, update channel, and terms implications for any hosted provider you might connect. We do not recommend using account pooling to evade provider limits.
The project currently documents this installation and setup sequence:
npm install -g @bitkyc08/opencodex
ocx start
ocx init
ocx health
ocx status
ocx start should bind its dashboard/proxy to 127.0.0.1:10100; ocx init wires Codex. Treat those as the project's documented behavior and verify the actual bind address locally. In the dashboard, add Ollama (local) with base URL http://127.0.0.1:11434/v1, then select the downloaded model. Do not choose "Ollama Cloud" or a hosted provider by accident. Do not enable OpenCodex's combo/failover routing for this privacy test. Disable the web-search and vision sidecars in the dashboard. Close and reopen the Codex desktop app so it reloads the model catalog, then select the routed local model.
On macOS or Linux, check listening sockets with lsof -nP -iTCP -sTCP:LISTEN. On Windows, inspect Get-NetTCPConnection -State Listen in PowerShell. The two local ports should not bind to 0.0.0.0 or a LAN address unless you deliberately designed and secured remote access. A local proxy bound beyond loopback is a different security project, not a convenience toggle.
Prove the Model Path Before Trusting It
Use a harmless prompt such as: "In this scratch repository, explain what README.md says; do not edit files or use web search." Confirm all of the following:
- The Codex app names the intended routed model and OpenCodex's request log shows the Ollama local provider, not a hosted route. Review the log for sensitive content before sharing a screenshot.
ollama psshows the model loaded during the request. That proves Ollama was involved, not that every byte stayed local.- The scratch repository remains unchanged. Check
git status --shortbefore and after. - Temporarily stop or isolate the Ollama service in a disposable test. The local-model request should fail rather than silently switch to a cloud model. Restore Ollama afterward. This is the negative test that catches unexpected fallback.
- Repeat with a controlled outbound-network block and firewall/DNS logs if you require an offline claim. Expect model downloads, account login, web search, remote tools, update checks, and sidecars to behave differently. An absence of obvious traffic in one short capture is not proof of universal offline behavior.
OpenCodex documents that its web-search sidecar defaults to an OpenAI backend when enabled and that its vision sidecar may send images to a hosted model. A text-only local model is not made private for image tasks merely because the final answer comes from Ollama. Inspect tool availability, not just the selected model name. Likewise, if you are signed into a hosted Codex account, separate account/authentication traffic from inference traffic in your audit.
Troubleshooting Without Guessing
| Symptom | First check | Likely next action |
|---|---|---|
| Model absent from app picker | ocx status, dashboard provider, app restart |
Recheck model discovery and catalog sync; do not hand-edit generated catalog files first. |
| Proxy appears healthy but replies fail | curl to Ollama /api/tags, exact model ID |
Fix the local runner or model fit before changing Codex. |
| Plain chat works; edits/tools fail | Model tool-call behavior and proxy request log | Test a tool-capable model on a scratch task; API compatibility is not agent competence. |
| "Local" answer unexpectedly uses web or image understanding | Sidecar settings and request destination | Disable sidecars and hosted routes, then repeat with outbound block. |
| App stopped working after setup | ocx health, bind address, current Codex config |
Use OpenCodex's restore path rather than stacking more config edits. |
OpenCodex says ocx stop stops the proxy and attempts to restore native Codex; ocx restore can restore routing without stopping it. Its documentation also notes that restoration can be incomplete if it cannot verify the current files. Preserve your own backup, compare the effective config after recovery, and restart Codex. Do not overwrite newer user changes with an old backup blindly.
Security, Privacy, and Recovery Boundaries
A local LLM can still make an unsafe tool request. The client decides whether to execute shell commands or apply edits, so keep approval and sandbox settings in force. Treat repository files, README instructions, web pages, and retrieved documents as untrusted input; OWASP identifies prompt injection as a risk even when the model itself runs locally. Keep secrets and customer code out of a first-run test, and review model/data licenses before using them in a workplace.
The illustrations in this article are editorial artwork, not screenshots of tested configuration. This guide explains a documented procedure; it does not certify that the latest Codex app, OpenCodex build, and model work together on every operating system. Record your versions, selected provider, negative fallback result, and egress trace before treating your own setup as verified.
Related TechGeeks Resources
- AI Workflow Notes: Start Here explains where local AI fits in a practical technical workflow.
- Local AI Homelab: Ollama and Open WebUI covers the surrounding local-model stack and hardware choices.
- Coding Agents in Docker Sandboxes covers execution boundaries once an agent can touch files and commands.
References
- XDA's OpenCodex article is the starting point for this independent guide.
- OpenCodex project, Codex integration, local providers, and sidecars.
- OpenAI Codex advanced configuration for native
--ossmode. - Ollama OpenAI compatibility, FAQ, and Qwen2.5-Coder model page.
- OWASP prompt-injection guidance.
