Roo Code: the local coding agent in the publisher

#What it is

Between code completion, which guesses the next line as you type, and the autonomous agent, which works alone in a container without continuous supervision, there is an intermediate category: the editor agent. It sees your open project, understands the file tree and its dependencies, suggests changes that you approve before they touch the disk, and runs commands in your terminal with your explicit approval each time. Roo Code belongs to this family, alongside projects such as Cline, with which it broadly shares the same philosophy.

Compared with a conversational assistant, the advantage is that there's no more copy-pasting: changes arrive as diffs in the relevant files. Compared with an autonomous agent, the advantage is that you stay in the loop at every step, which matters even more when the model is small. The project, released under the Apache 2.0 license, had surpassed 20,000 GitHub stars since its launch in late 2024, a rapid adoption rate in a category that had become highly competitive—before the shutdown announcement detailed below.

#The extension has been discontinued since May 2026: what changes

This is the most important information in this guide, and one that many tutorials still online fail to mention. Matt Rubens, the founder, announced on April 21, 2026, that Roo Code would be discontinued: the last release would be on May 15, 2026, followed by the GitHub repository being archived—locked to read-only, with no further fixes, including security fixes. A direct check of the repository confirms this: archived status and a latest commit dated May 15, 2026. The team has completely shifted to Roomote, a cloud agent controlled from Slack, judging that the code editor is no longer, in its view, the future of working with an AI agent.

#The modes, and why they are the right idea

Roo Code's distinguishing feature is that it separates personalities. Five modes are included by default: Code, for writing and editing with full tool access; Ask, a technical assistant that answers in detail but changes nothing (read-only and MCP access); Architect, a planner whose write permissions are limited to Markdown files, designed for planning before acting; Debug, focused on systematic diagnosis with full access; and Orchestrator, also called “Boomerang Mode,” which breaks down a complex task and delegates it to the other modes. You can still define additional modes, each with its own instructions and permissions.

With a local model, this is more than a convenience. An Ask mode that is not allowed to write eliminates the category of incidents where a model that is too small modifies a file out of excessive zeal. Restricting permissions by mode is the main way to make a small model usable without risk, and it also happens to be what brings Roo Code closest to a sound general security practice for agents: give each role only what it needs, never more.

#Connect it to a local model

1. 01
   Serve the model

   Ollama or any OpenAI-compatible endpoint. For individual use, Ollama is more than enough.
2. 02
   Choose Ollama as the provider in the extension

   Enter the model name or tag. The default base address is http://localhost:11434; an API key is required only if your Ollama server requires one.
3. 03
   Set the context window in the right place

   This is the most documented pitfall: by default, Roo Code uses the num_ctx setting defined in the Modelfile for model Ollama, rather than a value specific to the extension. Increasing the context must therefore be done on the Ollama side (Modelfile or environment variable), not in Roo Code settings.
4. 04
   Start in Ask mode

   Asking three questions about the project before allowing any modification, with a mode that has read-only permissions, gives you an honest measure of what the model actually understands about the code.

#Which model, really

A medium-sized code-oriented model almost always beats a larger general-purpose model at this task because it saw more strict formats and diffs during training instead of general prose. The difference is most visible in its ability to produce a diff that applies correctly on the first try, without a context or line-number error—a technical detail that matters more in practice than the overall quality of the model’s responses.

• Cline: the other editing agent, compared
• Help: the same idea, in the terminal
• Have a local model review your code

#Orchestrator: breaking down a complex task

Orchestrator mode, also called Boomerang Mode in the official documentation, changes how you approach a task that is too large for a single pass. Instead of directly asking “add authentication to my application,” you describe the goal to Orchestrator, which breaks it into subtasks and delegates them to specialized modes: Architect to create the plan, Code for implementation, and Debug if a test fails along the way.

1. 01
   Describe the goal, not the steps

   Give Orchestrator the expected result rather than the list of files to modify; that is precisely the breakdown the mode should produce.
2. 02
   Let each subtask return before starting the next

   The mode waits for the result of one delegation before launching the next, creating natural stopping points to review what has just been done.
3. 03
   Keep an eye on the active mode at every step

   The interface shows which mode is active at that moment; an unexpected switch to Code mode on a task that is supposed to remain read-only is the signal to monitor first.

With a local model, this breakdown has a direct, measurable cost: each delegated subtask is a new model call, meaning a new full generation with its own context-loading time. Orchestrator is worthwhile for a genuinely composite task involving multiple files and several distinct concerns; for a simple modification, it adds round trips without providing anything concrete, and direct Code mode remains significantly faster for reaching exactly the same final result.

#How to use it effectively

Narrow tasks

“Add this parameter and propagate it through the three functions that call it,” not “improve this module.” The more precise the request, the less room the model has to interpret it its own way—and that interpretive leeway is exactly what produces most disappointing diffs.

A clean repository

Working on a dedicated branch with a clean worktree makes every diff immediately readable and every mistake reversible in a reverted commit, without having to untangle the agent's modifications from your own ongoing changes.

Review every diff

A local model regularly produces plausible modifications that compile and pass a quick review, yet still do not actually do what you wanted. Compilation is not proof of correctness, only evidence that there is no syntax error.

Be wary of external content

A ticket, a dependency’s documentation file, or a comment already present in the code may contain an instruction intended for the agent rather than for you—see the security section below for what this concretely changes.

#Troubleshooting: the most common blockers

Most issues with a local model come from three recognizable and easily distinguishable causes that should be checked systematically before questioning the model’s intrinsic quality.

In all three cases, the first question to ask isn’t “which is the best model to use?” but “what context and permissions did the model actually receive when it responded?” Truncated context produces exactly the same visible symptoms as an undersized model, but the diagnostic cost and solution are very different once the real cause is identified.

#The risk inherent in an agent that reads your project

An editing agent naturally examines content you did not write yourself: a third-party dependency README, a ticket pasted into the conversation, or a comment already present in a repository cloned from elsewhere. Nothing prevents one of these contents from carrying an instruction intended for the model rather than for you—that is the very principle of prompt injection, detailed in the dedicated guide below—and an agent with a terminal and write access is a far more attractive target for this type of attack than a simple chatbot without tools.

This is precisely where Roo Code modes stop being merely an organizational convenience and become a concrete security measure. An Ask mode, restricted to reading, simply cannot execute the instruction hidden in a ticket even if it has read it and even if the underlying model was influenced by it. The protection does not come from a smarter model that can recognize the trap, but from a permission boundary that makes executing the instruction technically impossible, regardless of what the model decided to do.

• Prompt injection: local doesn't protect you
• Source: official documentation for Roo Code modes
• Source: the provider’s official configuration Ollama
• Source: Roo Code's official GitHub repository, archived status
• Source: account of Roo Code's shutdown and the alternatives (specialized press)

#FAQ