Local Coding Assistants: Codex CLI, Continue, Aider, and OpenHands

The short answer: choose Continue only if you accept its final, read-only 2.0.0 project state; choose Aider for a Git-first terminal loop; choose Codex CLI for an actively developed terminal agent with sandbox and approval controls; and choose OpenHands when you need a separate agent workspace and can operate its containers safely. In every case, start in a disposable branch with no production credentials and mount only the repository the tool needs.

This guide is for developers and homelab users who can read a Git diff and run their project's tests. It compares the tool layer, not just model quality, and covers four coding assistants:

• Codex CLI for terminal-based agent work with approvals and sandboxing.
• Continue for editor-based chat, edits, and autocomplete.
• Aider for Git-first pair programming in the terminal.
• OpenHands for more autonomous software-engineering tasks in a workspace.

The most important beginner rule: do not let an AI assistant freely edit your only copy of important code. Use Git, review diffs, and give it small tasks.

Quick Vocabulary

Interactive Coding Assistant Picker

Click each step to see what it means in a beginner-friendly local AI setup.

1Editor Helper2Terminal Edits3Agent Workspace4Codex CLI5Review Diff

Select a step

Choose a box above to view details.

ContinueEditor

AiderCLI

OpenHandsAgent UI

Codex CLIRepo agent

Term	Plain-English meaning
Repository, or repo	A project folder tracked by Git.
Branch	A safe copy of your project history where you can try changes.
Diff	A before-and-after view of what changed in your files.
Commit	A saved checkpoint in Git.
Local model	A model running on your own computer or homelab server.
Hosted model	A model running through a cloud API, such as OpenAI, Anthropic, Google, DeepSeek, or another provider.
Context	The code, instructions, terminal output, and chat history the AI can see.
Agent	An AI tool that can take actions, not just answer questions. Actions might include editing files, running tests, or opening pull requests.

The Big Idea: Tool vs Model

Beginners often mix up the assistant and the model.

The tool is the app you use. Codex CLI, Continue, Aider, and OpenHands are tools.

The model is the AI brain behind it. Examples include Qwen, DeepSeek, StarCoder2, OpenAI GPT models, Claude, Gemini, and many others.

Layer	Examples	What it does
Coding tool	Codex CLI, Continue, Aider, OpenHands	Reads your project, sends prompts to a model, applies edits, shows diffs, and may run commands.
Model runner	Ollama, LM Studio, vLLM, SGLang, llama.cpp	Runs local models on your machine or server.
AI model	Qwen3.6, Qwen3-Coder, Qwen2.5-Coder, DeepSeek-Coder-V2, StarCoder2, GPT, Claude, Gemini	Generates explanations, code, plans, and fixes.
Safety layer	Git branch, diffs, tests, sandbox, approvals	Keeps mistakes visible and reversible.

A good tool with a weak model can still make bad edits. A strong model with no Git safety can still break your project. You want both: a capable model and a safe workflow.

Four Tools at a Glance

Tool	Best beginner use	Runs where?	Local model friendly?	Watch out for
Codex CLI	Terminal agent that can inspect code, edit files, and run tests in the selected directory.	Your terminal.	Yes. Official OSS mode supports Ollama and LM Studio, and advanced configuration supports compatible local providers.	It can run commands and edit files, so keep sandboxing and approvals on.
Continue	Editor helper for chat, inline edits, autocomplete, and codebase questions.	VS Code, JetBrains, and CLI.	Yes. Continue documents Ollama and other local/self-hosted providers.	The official docs currently say the original Continue repo is read-only and that final 2.0.0 has shipped, so check project status before betting a long-term workflow on it.
Aider	Git-first terminal pair programmer that directly edits files and commits changes.	Your terminal.	Yes. Aider can use local models through Ollama or OpenAI-compatible local APIs.	It works best when your repo is in Git and your task names the exact files to change.
OpenHands	More autonomous agent workspace for larger tasks, GitHub issues, pull requests, and multi-step development.	Local GUI, Docker/runtime workspace, CLI, or OpenHands Cloud.	Yes, but it needs powerful models for good results.	Mount only the repo you want it to edit. A weak local model may struggle with long tasks.

When to Use Each Tool

Use Codex CLI When You Want a Terminal Agent

Codex CLI is useful when you want to stay in the terminal and ask an agent to inspect a repo, make edits, and run local commands. This is a good fit for tasks like:

• "Find why this test is failing and propose a fix."
• "Add validation to this function and update the unit test."
• "Review my local changes before I commit."

The key safety feature is the permission model. Codex docs describe sandbox modes such as read-only, workspace-write, and danger-full-access, plus approval policies such as on-request. For beginners, use the lower-risk path: work inside the project folder, keep workspace-limited permissions, and let the tool ask before network access or commands outside the workspace.

Good beginner prompt:

Look at this repo and explain how the login flow works. Do not edit files yet.

Then, after you understand the plan:

Fix only the failing login expiration test. Change the smallest amount of code possible, then run the relevant test command.

Use Continue When You Live in Your Editor

Continue is the most natural choice if you want AI help inside VS Code or JetBrains. It is especially friendly for:

• Asking questions about the file you are reading.
• Generating small inline edits.
• Getting local autocomplete.
• Connecting an editor to Ollama, LM Studio, or another model provider.

Continue supports different model roles, such as chat, edit, apply, autocomplete, and embeddings. That matters because autocomplete and chat are different jobs. A small local model may be fine for quick autocomplete, while a bigger model is better for planning a refactor.

Beginner setup idea:

Role	Suggested model type	Why
Autocomplete	Smaller local code model	Fast suggestions matter more than deep reasoning.
Chat	Medium or large local model, or hosted model	Code questions need more context and reasoning.
Edit/apply	Stronger code model	Bad edits cost more time than slow responses.
Embeddings	Small embedding model	Used for search and codebase awareness, not full code generation.

Status note: as checked on July 15, 2026, Continue's own docs say the original repository is read-only and that final 2.0.0 has shipped. That does not make the tool useless, but beginners should check the current extension, forks, or successor projects before designing a workflow around it.

Use Aider When You Want Git-First Pair Programming

Aider is a terminal-based coding assistant that works directly in your Git repo. Its Git integration is beginner-friendly because it can show diffs, commit AI changes, and undo changes.

Aider is a strong fit for:

• "Edit these two files."
• "Add a test for this bug."
• "Refactor this function without changing behavior."
• "Explain and fix this stack trace."

Aider is less ideal for "go explore my whole monorepo and redesign the architecture." It can work in large repos, but beginners should still give it the files that matter.

Good Aider-style prompt:

In src/cart/discounts.py and tests/test_discounts.py, add support for a 10 percent first-order discount. Keep existing behavior unchanged. Add or update tests.

Bad prompt:

Make my app better.

Use OpenHands When You Want a More Autonomous Workspace

OpenHands is closer to an AI software-engineering workspace than a simple autocomplete tool. It can work through a local GUI, cloud workflow, Docker-based runtime, and GitHub integrations. It is useful for:

• Working from GitHub issues.
• Creating pull requests.
• Running multi-step tasks.
• Using a browser-like or workspace-like agent environment.

OpenHands is also more demanding. Its docs say it needs a powerful model, and its local LLM docs warn that local models may have limited functionality. That does not mean you cannot use it locally. It means you should start with a small test repo before handing it your real project.

For local OpenHands, pay close attention to mounted folders. If you mount your whole home directory as writable, the agent can edit a lot more than you intended. Mount only the project repo, and use read-only mounts for reference material.

Local vs Hosted Models

Local AI homelab users usually care about privacy, cost, speed, and control. Hosted models usually win on raw coding ability and convenience. Local models win on control and offline use.

Choice	What stays local?	What leaves your machine?	Good for	Tradeoff
Fully local	Your prompts, code context, model inference, and responses stay on your machine or LAN, assuming your tool config does not send telemetry or use cloud services.	Usually nothing to the model provider. Package installs, web search, or plugins may still use the internet.	Private repos, offline tinkering, learning, cheap autocomplete.	Needs RAM/VRAM. Smaller models make more mistakes.
Hosted API	Your repo files remain on disk, but selected snippets and instructions are sent to the provider as context.	Prompts, code snippets, file contents, diffs, and command output that the tool sends.	Hard bugs, large refactors, agentic workflows, better reliability.	Costs money and requires trust in provider data policies.
Hybrid	Routine work can use local models; hard planning/review can use hosted models.	Only the tasks you route to hosted models.	Practical homelab setup for most people.	You must know which model is being used for each task.

If you are working on private code, read your tool and provider settings. "Local tool" does not always mean "local model." A terminal or editor extension can run locally while still sending code to a hosted model.

Coding Model Recommendations for a Homelab

Model recommendations change quickly. As of July 15, 2026, this is a practical beginner starting point based on current tool docs and model pages.

Your hardware	Start here	Good use	Beginner expectation
24 GB VRAM GPU, or Apple Silicon with 64 GB+ unified memory	Qwen3.6-35B-A3B	Local agentic coding, OpenHands experiments, repo-level reasoning.	Strong local choice, but still review every diff.
16-24 GB VRAM	Qwen3.6 27B, Qwen3-Coder 30B, or Qwen2.5-Coder 14B/32B depending on what fits.	Chat, edit, code review, medium tasks.	Good for scoped repo work. May struggle with long multi-file changes.
8-12 GB VRAM	Qwen2.5-Coder 7B, StarCoder2 7B, or another small code model.	Autocomplete, explanations, small functions, simple bug fixes.	Keep tasks tiny and include the exact files.
CPU-only or old laptop	Small 3B-7B code model, or use hosted models for hard work.	Learning, syntax help, small snippets.	Expect slow responses and more mistakes.
Production or high-stakes code	Strong hosted model for planning and review, local model for quick helper tasks.	Bugs, migrations, security-sensitive review.	Do not rely on one AI pass. Use tests and human review.

OpenHands currently recommends Qwen3.6-35B-A3B as a first local model to try for local OpenHands. Ollama also lists Qwen3.6 variants with a 256K context window and model sizes around 17-24 GB for common local variants. Qwen2.5-Coder remains a useful fallback family because it has many sizes from tiny to 32B. StarCoder2 is another code-focused family with smaller 3B, 7B, and 15B options.

For hosted coding, use the strongest model you can reasonably afford for tasks that involve architecture, debugging, security, or many files. Use cheaper or local models for autocomplete, simple explanations, and repetitive edits.

Why Smaller Models Need Scoped Tasks

Small local models can be useful, but they need tighter instructions. They usually have less reasoning power, smaller effective context, and weaker tool-use reliability than top hosted models.

Think of a small model as a helper who can do one clear job at a time.

Vague task	Scoped task
"Fix my website."	"In src/components/Navbar.tsx, fix the mobile menu so it closes after clicking a link. Do not edit other files."
"Clean up this repo."	"In scripts/backup.sh, add error handling when rsync fails. Show the diff before committing."
"Make auth secure."	"In auth/session.py, add a test for expired sessions and fix only the expiration check."
"Refactor the API."	"In api/users.py, extract duplicate email validation into one helper. Keep the public route behavior unchanged."

Use this rule of thumb:

Model size	Task size to give it
3B-7B	One function, one file, one test, or one explanation.
14B-32B	A few related files, one bug, one feature slice.
35B+ strong coding model	Multi-file tasks, but still with a clear boundary.
Top hosted model	Larger planning and refactors, but still review in small commits.

The model does better when you provide:

• The exact files to inspect.
• The error message or failing test.
• The command to run tests.
• A clear "do not edit outside this area" rule.
• A request to explain the plan before editing.

Git and Diff Safety

Before using any coding assistant on a real repo, make Git your safety net.

Step	Command	Why it matters
Check your repo	git status	Shows whether you already have unsaved work.
Create a branch	git switch -c ai-test-login-fix	Keeps AI changes separate from your main branch.
Review summary	git diff --stat	Shows which files changed.
Review details	git diff	Shows the actual line-by-line edits.
Run tests	Project-specific, such as npm test, pytest, or go test ./...	Confirms the change did not obviously break the project.
Commit when happy	git add . && git commit -m "Fix login expiration test"	Saves a checkpoint you can return to.

Safety checklist:

• Start from a clean branch when possible.
• Never let an assistant edit secrets, .env files, SSH keys, API keys, production credentials, or password files.
• Do not approve commands you do not understand.
• Be careful with rm, sudo, chmod, chown, curl | sh, database commands, cloud CLIs, and package manager scripts.
• Review lockfile changes, generated files, and dependency updates.
• Keep edits small enough that you can understand the diff.
• If the diff is confusing, ask the assistant to explain it before you run it.

Tool-specific safety notes:

Tool	Safety habit
Codex CLI	Keep workspace-limited sandboxing and approval prompts on for normal work. Avoid full-access modes unless you understand the risk.
Continue	Use editor diffs and source control view before accepting broad edits. Separate autocomplete from agent/edit actions.
Aider	Use a Git repo. Learn /diff, /undo, and its auto-commit behavior before touching important code.
OpenHands	Mount only the repo you want edited. Use read-only mounts for reference files. Bind local services to 127.0.0.1 when possible.

A Beginner Repo Edit Loop

Use this loop with any of the tools:

1. Prepare: Make a branch and check git status.
2. Scope: Tell the assistant the exact task and files.
3. Plan: Ask for a plan before edits if the task is not tiny.
4. Edit: Let the assistant make the smallest useful change.
5. Review: Read git diff --stat and git diff.
6. Test: Run the narrow test first, then broader tests if needed.
7. Commit: Save the good change.
8. Repeat: Start the next small task.

Starter prompt:

You are helping me make a small, safe code change.

Task:
Fix the expired-session test without changing unrelated authentication behavior.

Files to inspect first:
- auth/session.py
- tests/test_session.py

Rules:
- Explain your plan before editing.
- Change only the files needed for this task.
- Do not edit secrets, config files, generated files, or dependencies unless I ask.
- After editing, show me what changed and tell me what test command to run.

Suggested Tool Selection

If you want...	Pick...	Why
AI help inside VS Code or JetBrains	Continue	It is built around editor workflows, chat, edits, autocomplete, and model configuration.
A terminal pair programmer that loves Git	Aider	It edits repo files directly and has strong Git/diff habits.
A terminal coding agent with local command execution and approvals	Codex CLI	It can inspect, edit, run commands, and work inside permission boundaries.
A more autonomous engineering workspace	OpenHands	It is designed for agentic software development tasks, GitHub workflows, and runtime workspaces.
Maximum privacy	Continue or Aider with Ollama/LM Studio, or local OpenHands	Keep model inference local, but verify tool telemetry and plugin settings.
Maximum coding quality	Hosted strong model through the tool that fits your workflow	The strongest hosted models usually outperform small local models on hard tasks.
Learning safely	Continue or Aider on a toy repo	Fast feedback, easy diffs, lower blast radius.

Common Beginner Mistakes

Mistake	Safer habit
Running an agent in your home directory.	Run it inside one project repo.
Asking for a huge refactor first.	Ask for one small feature or one failing test.
Not using Git.	Create a branch before the assistant edits files.
Accepting a diff you do not understand.	Ask the assistant to explain every changed file.
Using a tiny model for big agent tasks.	Use small models for scoped edits and bigger models for planning.
Letting the assistant install random dependencies.	Ask why the dependency is needed and review package.json, lockfiles, or equivalent files.
Treating passing tests as proof of correctness.	Passing tests are useful, but still read the code.

A Practical Homelab Setup

For a beginner-friendly local coding lab, start simple:

1. Install Ollama or LM Studio on the machine with the most RAM/VRAM.
2. Pull one small model and one stronger model that fits your hardware.
3. Connect Continue for editor chat/autocomplete.
4. Try Aider on a small Git repo.
5. Try Codex CLI or OpenHands only after you are comfortable reviewing diffs.
6. Keep a toy repo called ai-sandbox where you test new tools before pointing them at real projects.

Example local model split:

Job	Model style
Fast autocomplete	Small code model, 3B-7B.
File-level edits	Medium code model, 7B-32B.
Agentic repo work	Strong local model such as Qwen3.6-35B-A3B if your hardware can run it, or a hosted model.
Final review	Strongest model available plus human review.

Evidence and Evaluation Method

Evidence status: this comparison is documentation-backed and was fact-checked on July 15, 2026. It reflects current Codex, Continue, Aider, OpenHands, Ollama, and model documentation. TechGeeks did not run a matched coding benchmark across all four tools or independently test their sandbox boundaries for this revision. The procedure below is a planned reader evaluation, not a claim of completed lab testing.

1. Build a disposable fixture repo. Include one documented bug, a failing test, a lint rule, an ignored secret-shaped canary file containing no real credential, and an out-of-scope sibling directory. Take a snapshot or commit before each tool run.
2. Freeze the configuration. Record tool and model versions, provider, context, sandbox or runtime type, approval policy, mounted paths, network access, plugins, MCP servers, and prompt. A tool comparison is meaningless if each candidate receives different permissions.
3. Repeat the same task. Run several fresh trials. Score whether the bug is fixed, the named test passes, unrelated tests regress, files outside scope change, a new dependency appears, commands require approval, and the final explanation matches the diff.
4. Inspect the trajectory. Save proposed commands, tool arguments, errors, retries, elapsed time, and final diff. Passing tests alone do not show whether the agent attempted an unsafe command or used a hidden network dependency.
5. Test the boundary. Deny WAN egress and DNS, reject a request to read the canary and sibling directory, cap CPU and RAM, and stop the run at its time limit. The expected result is a clear denial or controlled failure, not a silent fallback to broader access.
6. Destroy and recreate. Remove the sandbox, recreate it from the clean commit, and confirm no tool state, generated credential, background process, or writable mount survives unexpectedly.

OpenHands now calls its execution environment a V1 sandbox. Its current documentation recommends the Docker sandbox and labels the process sandbox unsafe because it has no container isolation. A container is still not a complete security boundary, especially when it receives the Docker socket, broad writable mounts, host networking, or secrets.

Recovery, Privacy, and Legal Boundaries

Recovery starts before the agent: preserve the user's dirty work, create a branch, record the starting commit, and know whether the tool auto-commits. Aider normally commits edits and can also commit pre-existing dirty files; review that behavior and whether pre-commit hooks run before using it. If the result is wrong, stop the agent, save the transcript and diff, and revert only the agent's identified commits or restore the disposable workspace.

If a tool reaches a secret or unauthorized service, end the session, disable its network and provider access, revoke the credential, preserve logs, and inspect every command and outbound request before resuming. Deleting the branch does not invalidate an exposed token or undo an API call, message, deployment, database migration, or package publication.

Hosted providers may receive prompts, file excerpts, diffs, logs, and tool results. Local inference reduces that route but does not control telemetry, plugins, package installation, web access, or remote MCP servers. Follow repository licenses and employer or client policy; do not submit third-party confidential code merely because a tool can read it. AI-generated code still needs license, security, and provenance review.

What This Comparison Does Not Prove

• Tool documentation does not prove a sandbox resists every escape, malicious dependency, compromised image, or unsafe user approval.
• A local provider connection does not prove the coding tool sends no telemetry or that plugins and package managers remain offline.
• One successful edit does not establish reliability on large refactors, unfamiliar languages, migrations, security fixes, or production incidents.
• A benchmark score does not show whether the model follows your repo instructions, produces reviewable diffs, or uses your tool's edit format correctly.
• A passing generated test may only confirm the agent wrote a test that agrees with its own bug. Human review and independent acceptance criteria remain necessary.

Related TechGeeks Reading

• Implementing AgenticOps Safely
• AI Workflow Notes: Start Here
• Docker Compose for Normal People

References

• OpenAI Developers, Codex CLI
• OpenAI Developers, Codex sandboxing
• Continue Docs, Continue overview
• Continue Docs, Model providers overview
• Continue Docs, config.yaml reference
• Aider Docs, Connecting to LLMs
• Aider Docs, Git integration
• Aider Docs, Usage
• Aider Docs, FAQ
• OpenHands Docs, Introduction
• OpenHands Docs, LLM overview
• OpenHands Docs, Local LLMs
• OpenHands Docs, Docker runtime
• OpenHands Docs, current V1 sandbox overview
• OpenHands Docs, GitHub integration
• Ollama Blog, OpenAI compatibility
• Ollama Library, Qwen3.6
• Ollama Library, Qwen3-Coder
• Ollama Library, Qwen2.5-Coder
• Qwen on Hugging Face, Qwen3.6-35B-A3B
• DeepSeek GitHub, DeepSeek-Coder-V2
• BigCode GitHub, StarCoder2
• NIST NCCoE, software and AI agent identity and authorization concept
• Docker, coding-agent sandbox threat and isolation discussion