Someone says, “This is getting complex. We should write this down.”

No one wants to stop and create a doc.

Now there’s another option: mention @Roomote in the thread.

Roo Code’s agent reacts with 👀. You can pick an agent, or let Roo Code handle it for you. Then choose a repository. Roo Code reads your entire discussion and returns a structured spec, right in the thread. Your team refines it. Then you call @Roomote to build it. A branch gets pushed. A PR opens. Work gets shipped.

Discussion → plan → code. Without leaving Slack.

What this actually looks like

Here’s a real flow:

> Designer: What if we add a dark mode toggle to the settings page?

> PM: Users have been asking for this. Should persist across sessions.

> Engineer: Need to think about system preferences too. Auto vs manual.

> PM: Good points. Let’s not lose this.

> @Roomote plan out a dark mode feature based on our discussion. Include the toggle, persistence, and system preference detection.

The Planner agent reads the thread, understands what “this” means, and produces a spec. The team reviews it in Slack. When it looks good:

> Engineer: This looks good. Let’s build it.

> @Roomote implement this plan in the frontend-web repo.

The Coder agent creates a branch and opens a PR. The engineer reviews and merges.

The agents know your thread

This is the part that’s incredibly powerful:

You can be mid-conversation with a colleague, debugging something confusing. After a few back-and-forth messages, you just type:

> @Roomote why is this happening?

And it knows what “this” means. The agent reads the thread history before responding. No need to re-explain the context you just spent 20 messages establishing.

Non-technical team members can use this too

A CSM pastes an error in Slack:

> “Customer is seeing `Error 403: Token validation failed` when trying to export. Anyone know what this is?”

Usually: silence. Engineers are heads-down. The CSM escalates urgently or waits.

With @Roomote, the CSM asks the agent to explain. The agent reads the codebase, explains what’s happening in plain language, and can even push a fix branch if needed. The CSM updates the customer without waiting for engineering.

PMs can investigate hypotheses. Support can triage issues. Engineering gets pulled in only when humans need to make decisions.

Safe by design

Agents never touch main or master directly. They push branches and open PRs. You review. You approve.

The boundary stays with you and your team.

This matters. Agents produce artifacts; humans decide what ships.

Check it out in action:

Full video here: https://lnkd.in/gaX9J2DT

Get started here: https://roocode.com/slack

While the world was wrapping gifts, we were wrapping infrastructure.

In December 2025, the Roo Code team pushed 166 commits and added 88,000+ lines of code to Roo Code Cloud. This was not just maintenance. It expanded where agents can run, what they can integrate with, and what kind of environments they can depend on.

We pushed on three concrete capabilities: deeper workflow integration (Linear), a second compute vendor (Vercel Sandbox), and on-demand services (so the agent environment matches your app).

Here is what we shipped to shrink the “works on my machine” gap.

1) Linear integration: stop copy-pasting tickets

(Landed Dec 28; PR #1945, #2000)

The struggle: Your team’s work lives in Linear, but your code lives somewhere else. You become the human router (copy issue description, paste into prompt, recopy updates). It is pure toil.

The fix: We built a full Linear integration. It connects via OAuth, carries issue context into the agent run, and syncs back useful artifacts (status, actions, plans).

So you can: Start work from a Linear issue without rebuilding context by hand, and track progress where the team already lives.

2) Vercel Sandbox: cloud tasks you can see

(Dec 19–23; PR #1937, #1943)

The struggle: Remote compute is great until it is opaque. If you cannot open what the agent is running, you either trust blindly or switch back to local just to see the localhost port.

The fix: We added Vercel Sandbox execution alongside Fly.io and surfaced task preview links. You can open what the job is serving while it runs.

So you can: Stop guessing. Open the preview, watch the app change, and treat cloud tasks like something you can interact with.

3) Services Manager: databases on demand

(Dec 23; PR #1951, #1956)

The struggle: A blank container is not a development environment. “It compiles” is not the same as “it runs.” If your feature needs Postgres but the agent has no database, the code fails the second it hits CI.

The fix: We shipped the Services Manager. You can now configure roomotes.yml to request ephemeral services like Redis 7, Postgres 17, or ClickHouse.

So you can: Give the agent a real environment to run migrations and integration checks. Catch the “it fails when it touches the database” class of bugs earlier.

Tradeoff: spinning up real services can add time to a run. That is the cost of catching the right failures early.

4) The unified Fixer agent

(Dec 10–12; PR #1872, #1894)

The struggle: Separate fixers with different behaviors create a new kind of work. You end up learning which bot is safe to trust today.

The fix: We unified the PR Fixer and Issue Fixer into a single Fixer agent and enforced approval requirements before implementing issue fixes.

So you can: Stop guessing. Whether it starts from an issue, a PR comment, or a message, the control boundary stays predictable.

The theme: Connection

December was about connecting the parts that usually break a workflow.

• Workflow connection: Linear issues to agent sessions.

• Compute connection: Fly.io plus Vercel Sandbox as places work can run.

• Data connection: Services that match what your app expects.

Roo Code Cloud is not a place to run scripts. It is a place where agents can do real product work, with visible execution and clear control boundaries.

If you want a quick way to try the new flow, start from a Linear issue, keep approvals on, and open the task preview while it runs.

Let’s ship.

Want to try Roo Code Cloud? Start here.

Most of the industry slows down in December. We accidentally (on purpose, because we are your mildly unhinged group of agent makers) did the opposite.

Between December 1st (v3.35.0) and December 31st (v3.38.2), we shipped 28 releases. Why? Because we found a way to make your agents significantly smarter without waiting for the next model release (yes, including GPT-5.2-Codex).

We went after the unglamorous, critical plumbing: moving tool use onto native formats, tightening context architecture, and making debugging actionable. The goal was simple: remove friction so closing the loop feels straightforward.

We kept seeing the same opportunity: if we fix the plumbing, we unlock a new level of performance for every model you use.

Here is how we upgraded your engine.

1) Agent Skills: Superpowers on Demand

(Landed in v3.38.0; aligned to spec in v3.38.2)

The problem: if you stuff every tool and rule into the system prompt “just in case,” you burn tokens and distract the model.

The fix: we shipped Agent Skills. Think of these as modular superpowers. Instead of carrying the kitchen sink at all times, the agent can load specific capabilities (tools, prompts, resources) only when the task actually requires them.

So you can: build agents with deep expertise in specific domains without crushing their context window.

Tradeoff: skills add setup and coordination. The payoff is a cleaner context window and more predictable behavior.

2) Native Tool Calling: A Massive Performance Unlock

(Shipped continuously across December releases)

The problem: you think the model is “hallucinating.” A lot of the time it is just overstimulated. Asking an LLM to execute code by parsing brittle text formats is like trying to solve a LeetCode Hard during a fire drill (this is fine). It burns cognitive energy on the formatting, so it has less brainpower left to actually solve the bug.

The fix: we pushed tool use onto native tool calling across providers (Roo Code Router, Anthropic, OpenAI, OpenRouter, etc.). We deprecated XML tool protocol selection for new tasks. We stopped forcing models to act like 1990s text parsers.

The upside: the difference is not subtle. In one internal eval, Claude 4.5 Haiku went from ~27% to ~95% success after the shift. If we publish this number, we should add one sentence defining the eval and sample size.

So you can: get top-tier results from the “fast and cheap” models. And you still keep full control with approvals. Roo Code does not execute without you saying so.

3) Fixing “Agent Amnesia” (Context Management)

(v3.36.1 and v3.36.3)

The problem: long tasks tend to rot. As the context window fills up, the agent gets confused. Suddenly you are re-explaining a file Roo Code read fifteen minutes ago. It’s exhausting.

The fix: we rewrote the MessageManager layer. History coordination and truncation are infrastructure now, not a coincidence.

So you can: spend tokens intentionally on results, not on reminding the agent what day it is.

4) Debugging: Showing the Receipts

(v3.36.4, v3.36.14, v3.36.15)

The problem: the shift to native tool calling was a massive upgrade. It also exposed weird edge cases. APIs failed in creative ways we had not seen before, and “Something went wrong” does not cut it when you are debugging protocol mismatches.

The fix: we took the medicine. We stopped hiding the underlying error details and shipped an Error Details Modal and Downloadable Diagnostics. We also improved reliability for tool execution edge cases.

So you can: see why it crashed instead of guessing. Huge shoutout to the community for the patience and the detailed bug reports while we stabilized the plumbing.

Ready for 2026?

December was not just a shipping spree. It was an engine swap. We stripped friction, fixed plumbing, and handed brainpower back to the agent.

If you haven’t updated since November, you are running on an older, slower engine.

Get started with Roo Code

In 3.36.0 we introduced native tool calling and started migrating through the 3.36.x releases. In 3.37.0 we made native tool calling the default and removed XML tool calling entirely.

This was not a knee-jerk move. New models now ship with first-class native tool calling support that goes far beyond anything we could realistically achieve with XML. Continuing to invest in XML would anchor Roo to an approach the ecosystem is already moving away from.

Some people have asked why we did not keep XML as an option. Keeping two tool calling architectures massively increases complexity. Every fix, every feature, every tool-related issue forces Roo to reason about two completely different execution paths. That slows development, increases bugs, and makes it harder to move Roo forward. It also guarantees that XML users would slowly get stuck with an increasingly outdated experience as improvements land only in the native path.

This transition has been a pain in the ass, and we know it. We chose to ship when we did based on live metrics, real usage, and incoming bug reports. We knew there would be collateral damage. We tried to minimize it, but this is the largest architectural change Roo has ever gone through.

Right now we are focused on debugging and buttoning up the native tool calling implementation, especially around edge cases. Telemetry shows it is working for the vast majority of users, but we are not pretending this is finished. With many providers, many models, and users constantly switching between them, there is real complexity here. The error reports people send in are incredibly valuable and directly drive fixes.

There is also a bigger reason for doing this now. Over the last two months we have been heavily reworking Roo’s foundation mid-stream. Context handling, task orchestration, and core execution paths are being rebuilt to support some very large features planned for early 2026. Native tool calling is required for that work. Staying on XML would have blocked it outright.

Merry Christmas. We have taken a short break for the holidays, and we are genuinely sorry if you are one of the people whose Roo issues did not get resolved in the final crunch before the break. If you need stability right now, you can roll back to 3.36.16 and select XML tool calling as your default in the advanced settings of your API profiles.

We know this has been frustrating. We are sorry for the pain in the ass this caused. We appreciate the patience, the blunt feedback, and the bug reports.

XML tool calling is retired. Native tool calling is how Roo moves forward.

Why you’ll love it

Instant collaboration
Stuck on a gnarly prompt? Paste a share-link to a teammate and they can step through every move you made—no screen-share, no “can you scroll up?” With all the context in one place, the fix often appears in minutes.

Smarter code reviews
Add a share-link to your next PR description. Reviewers see why the code exists, not just what changed: fewer back-and-forth comments and faster merges.

Team playbooks & best practices
When you discover a prompt that sings, turn it into a living example for the whole squad. A single link becomes an evergreen reference others can study, fork, and improve.

Show-and-tell moments
Built something wild (or hilariously unexpected)? Drop the link on Twitter, Reddit, or in our Discord and let the applause—or constructive roasting—roll in.

🔒 Heads-up on privacy: Share-links expose chat and task metadata only—not your raw source code—and are visible solely to anyone holding the link.

How it works

1. Update Roo Code to the latest build (it’s live now).

2. Open any completed (or failed!) task in the sidebar.

3. Hit Share 🔗 → Copy link.

4. Paste the URL wherever you need a second pair of eyes—or a round of applause.

If the viewer isn’t logged in, they’ll be prompted to create a free Roo Code Cloud account so they can watch the replay. No setup, no permissions dance.

What’s next

“Sharing” is the first tile in a much bigger Roo Code Cloud mosaic. Over the coming weeks we’ll drip out more tricks that build on the same link model. But for now, we just want to see what you create.

Try it now

Fire up Roo Code, share your most interesting task, and tag @roocode on X or LinkedIn. We’ll reshare our favorites and maybe toss in some swag for the most mind-bending examples.

Happy Roosharing!

At first, I was a little skeptical:

"Thanks for the PR! I’ll take a look at this soon. In general I haven’t thought a ton about the internationalization strategy—curious what people have seen work in the past. Just using internationalized strings when developing and letting the community translate as follow-ups?"

The contributor responded with a thoughtful note:

"Thanks for the response! I’m currently promoting the Roo Code plugin to my colleagues, and in order to help everyone better understand the meaning of the menu settings, I’ve implemented internationalization. I personally believe that using internationalized strings during development helps developers from different countries better understand the meaning of the menu settings."

And honestly? They were right.

In the old world (a.k.a. 2024), it would have been unthinkable for a fast-moving project like Roo Code to pause and set up a full internationalization pipeline. That kind of thing was the domain of big, slow-moving companies with dedicated teams. But things have changed. LLMs are here, and Roo Code has... Roo Code.

We also started to notice something else: a large portion of our community contributions were coming from non-native English speakers. Roo Code is deeply community-driven, and if our users are global, our interface should be too.

So, we decided to go all-in on internationalization.

Step 1: Internationalize Everything

At first, we thought we’d slowly internationalize the app, one screen at a time. But again, this is 2025. Why not just... do it all?

So we spun up a custom mode called "Internationalization Engineer" inside Roo. This agent specialized in extracting all the user-facing English strings from our codebase and organizing them into clean, well-named JSON files. If you’ve ever done this job manually, you know it’s a nightmare. But Roo didn’t complain - and it crushed it for single files.

The next challenge: scale.

You can’t just tell an LLM, “Internationalize the whole thing,” and expect it to get through the the entire application. That’s where our orchestration features came in.

We used Roo’s “Boomerang Mode”, a high-level workflow that breaks down large tasks into subtasks and delegates them out without clogging up the context window. We pointed the orchestrator at the whole extension, and it got to work:

• It created a list of every file that needed internationalizing

• It handed each one off to the Internationalization Engineer

• It stitched everything back together, clean and fast

I’d love to say I watched it work, but honestly, I went and played with my kids while Roo handled it. When I came back, it was done.

Step 2: Translate

Next came translation.

LLMs have been good at translation for a while, but consistency is tricky. So I created a custom “Translate” mode filled with detailed instructions: voice, tone, how to handle pluralization, how to treat interpolated variables, etc.

We ran a few test translations and sent them to our original contributors for review. The feedback was great! A few small tweaks (like keeping “tokens” in English instead of translating) and we updated our instructions and re-ran everything. Total fix time: a few minutes.

We ended up translating Roo Code into 14 new languages in a little over a week of one developer’s time, plus a heavy assist from Roo (and a decent number of tokens). The results weren’t perfect, but they were a huge head start.

Step 3: Learn and Improve — Automatically

As we expected, some native speakers from the community sent in pull requests with fixes and improvements to the initial translations. In the old world, this would be a constant tax: humans doing slow reviews, keeping documentation up to date, and hoping translators got the memo next time.

But this is Roo Code in 2025.

Instead of just merging the PRs and moving on, we pointed Roo Code at the feedback itself. Roo reviewed the pull requests, summarized the changes, and then updated its own custom instructions - adding examples and new heuristics to handle similar edge cases in the future.

In other words: Roo learned.

This created a positive feedback loop. The more feedback the community gave, the better Roo got at translating the next thing. Suddenly our translation strategy wasn’t just “generate and fix,” it was “generate, fix, and get better automatically.”

2024 internationalization couldn’t do that.

The Takeaway

This whole project has been one of the clearest examples of how Roo Code helps build Roo Code, and why we’re so excited about the future of AI-assisted software development.

Internationalization used to be a multi-quarter initiative. Now it’s just... a thing we did in a week.

We’re shipping faster than ever, with a more inclusive product, thanks to the power of LLMs and the amazing Roo community that pushes us to keep leveling up.

The world’s not waiting, and neither are we.

Roo Code is an open-source AI coding assistant that lives in your editor and helps you build faster with agent-based workflows. It’s available now as a VS Code extension and on GitHub.