Local Coding Assistants: Codex CLI, Continue, Aider, and OpenHands
Tech GuruThe short answer: compare Continue for editor workflows, Aider for Git-first terminal edits, Codex CLI for a terminal agent with sandbox/approval controls, and OpenHands for an agent workspace you can operate safely. Start with a disposable repository and no production credentials. Choose the exact release and model together; the tool name alone does not establish isolation or task quality.
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.
Choose a box above to view details.
| Term | Plain-English meaning |
|---|---|
| Repository, or repo | A project folder tracked by Git. |
| Branch | A named line of Git history, not a separate filesystem copy, backup or sandbox. |
| 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. | Current docs describe editor and CLI workflows; verify the installed extension, provider and permissions. Repository availability is not a long-term support guarantee. |
| 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 offers editor chat, edits and autocomplete in VS Code and JetBrains. Evaluate it against the editor actions you actually use:
- 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 checked October 2, 2026: Continue's current documentation describes its extensions and CLI. The official GitHub API reports archived=false and disabled=false for continuedev/continue. The earlier claim that the project was permanently read-only at a final 2.0.0 release is not supported by this check. Verify the specific extension release and security history before deployment.
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 spans several agent interfaces and execution backends. Current docs distinguish Agent Canvas, local model serving and local project-file access; older local GUI/CLI pages are now under Deprecated Projects. Select the interface and release before following setup instructions. Typical use cases include:
- 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
Compare local and hosted providers on your fixed task set, with equal permissions and independent acceptance tests. Local inference changes where model requests are processed; hosted inference changes infrastructure and data-handling obligations. Neither location alone establishes coding accuracy or reliability.
| 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
The table preserves model candidates from the July 2026 comparison, not measured fit or quality rankings. Match the exact quantization, context, tool-call format and concurrency to the runtime. OpenHands' current guide still proposes Qwen3.6-35B-A3B as a first local candidate, but its documented hardware guidance is not a benchmark of this setup.
| 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. | Vendor starting candidate; test memory fit and tool use, then 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 | An independently evaluated model under approved data-handling and execution controls. | 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 architecture, debugging or security changes, evaluate task completion, regressions and unsafe attempts rather than selecting by price tier or advertised model strength. A second AI review is not independent human approval, and neither replaces the project's test and release process.
Why Smaller Models Need Scoped Tasks
Scope tasks for every model. A nominal parameter count does not determine the number of files an agent can safely edit; use the table below only as a starting experiment, then score actual changes, tool failures and regressions.
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 staged, unstaged and untracked on-disk changes; save editor buffers separately. |
| 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 -p -- auth/session.py tests/test_session.py, then git diff --cached; commit separately after review | Example paths only. Stage reviewed hunks, inspect the entire index, then create the intended commit. |
Before staging, inspect git status and git diff --cached for pre-existing work. The example paths above must match your task; git add -p does not automatically include new untracked files. Add any intended new file by its exact path after reading it. A commit includes all staged changes, so stop if the index contains unrelated work rather than silently including or clearing it.
- Start from a clean branch when possible.
- Never let an assistant edit secrets,
.envfiles, 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:
- Prepare: Make a branch and check
git status. - Scope: Tell the assistant the exact task and files.
- Plan: Ask for a plan before edits if the task is not tiny.
- Edit: Let the assistant make the smallest useful change.
- Review: Read
git diff --statandgit diff. - Test: Run the narrow test first, then broader tests if needed.
- Commit: Save the good change.
- 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. |
| Evaluate local inference | Continue or Aider with Ollama/LM Studio, or local OpenHands | Keep model inference local, but verify tool telemetry and plugin settings. |
| Evaluate coding quality | Hosted strong model through the tool that fits your workflow | Compare exact models on representative tasks; no matched quality ranking is established here. |
| 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:
- Install Ollama or LM Studio on the machine with the most RAM/VRAM.
- Pull one small model and one stronger model that fits your hardware.
- Connect Continue for editor chat/autocomplete.
- Try Aider on a small Git repo.
- Try Codex CLI or OpenHands only after you are comfortable reviewing diffs.
- Keep a toy repo called
ai-sandboxwhere 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
The cited OpenHands V1 page calls its execution environment a sandbox and recommends Docker over the process provider, which lacks container isolation. That page now sits under deprecated local GUI documentation; confirm the selected interface's current backend behavior. Docker socket access, broad writable mounts, host networking and injected secrets can defeat the intended boundary. A project directory or Git branch does not constrain those capabilities.
Recovery, Privacy, and Legal Boundaries
Preserve dirty work and record the starting commit before an agent runs. Aider normally commits edits and can first commit existing dirty files; use --no-auto-commits and --no-dirty-commits when manual commits are required. Its default skips pre-commit hooks; --git-commit-verify enables them. Choose that policy explicitly. If a run is wrong, preserve its transcript/diff and undo only identified agent changes or recreate the disposable workspace; never discard unrelated work.
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
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
One thought on “Local Coding Assistants: Codex CLI, Continue, Aider, and OpenHands”