Roo Code: Governing a Coding Agent Through a Gateway

What Roo Code is — and what changed

Roo Code was an intelligent code-generation and refactoring system that worked within VS Code using natural language commands and context information from your coding activity. It was popular, open-source, and powerful.

In May 2026, Roo Code’s vendor announced it was shutting the extension down and directed users to Cline, a closely related agent. Existing installs keep working, but there are no new releases. That makes this a two-audience topic: teams still running Roo Code who need to keep it under control, and teams moving to Cline who want to set governance up correctly from day one. The good news is that both are governed the same way, because both connect through a standard OpenAI-compatible endpoint.

Whichever way you operate, the fundamental issue is basically the same – although not because of the extension.

Why a coding agent needs governance

An IDE coding agent is one of the least-governed LLM clients in most companies. Think about what it does by default:

• It holds a raw provider API key, typed into each developer’s settings. Rotating or revoking access means touching every machine.
• It calls whatever model the developer picks, with no central policy on which models are allowed or how much they cost.
• It sends your source code to a model provider — proprietary logic, secrets in config files, customer data in fixtures — with no scanning or redaction.
• It generates heavy, bursty token usage as it reads files and iterates, and none of that spend is attributed to a team or capped.
• It leaves no audit trail anyone can review.

Multiply that across a fifty-person engineering org and you have real spend, real data-exposure risk, and zero visibility. The agent is useful; the lack of a control point is the problem.

What “governed” actually means

Governance here is not about restricting the agent — it’s about putting a control point between it and the model providers. That control point is the gateway.

Every Roo Code (or Cline) instance points at one gateway endpoint instead of a provider directly. The gateway then enforces policy on every request:

• Cost tracking per developer, team, and model — so agent spend is a line item you can see and attribute, not a surprise.
• Budgets and rate limits that cap a runaway agent before it burns a month’s quota in an afternoon.
• A model allowlist — the gateway decides which models the agent may call, regardless of what the IDE dropdown offers.
• Secret and PII guardrails that scan prompts and code for leaks before they reach a provider.
• An audit log of every agent call, for security and compliance review.
• Fallback so a provider outage doesn’t stop every developer at once.
• No raw provider keys on laptops — developers hold a TrueFoundry token; the real keys live in the gateway.

Where teams get this wrong

They hand out provider keys to developers. Every laptop with a raw OpenAI or Anthropic key is a rotation headache and a leak waiting to happen. Issue gateway tokens instead.

They govern production LLM calls but ignore the IDE. The coding agent often sends more sensitive data than production — your actual source — yet runs with none of the guardrails. Bring it under the same gateway.

They assume the IDE can be locked down. Roo Code’s provider settings are per-user; there’s no documented admin lockout. Chasing client-side enforcement is the wrong layer. Enforce at the gateway, where it actually holds.

They skip code/secret scanning. A coding agent will happily paste an .env file into a prompt. Without guardrails, that secret leaves your perimeter.

Want every developer’s AI coding spend in one governed view?

Book a demo

How to point Roo Code (or Cline) at the gateway

The setup uses the agent’s OpenAI-compatible provider. First, grab your gateway base URL and model name from the TrueFoundry playground’s unified code snippet.

In Roo Code, open the sidebar, choose “OpenAI Compatible” (or “Custom”) as the API provider, and enter your gateway base URL, the model name, and your TrueFoundry token.

Save, then test by asking the agent to work on a file — the response now flows through the gateway.

You can define multiple profiles for different tasks — a high-quality model for complex generation, a cheaper one for quick edits — all through the same gateway:

{
  "roocode.apiProfiles": [
    {
      "name": "TrueFoundry — high quality",
      "baseUrl": "{GATEWAY_BASE_URL}",
      "apiKey": "your-truefoundry-token",
      "model": "anthropic-account/your-strong-model",
      "description": "Complex code generation"
    },
    {
      "name": "TrueFoundry — fast",
      "baseUrl": "{GATEWAY_BASE_URL}",
      "apiKey": "your-truefoundry-token",
      "model": "openai-account/your-fast-model",
      "description": "Quick edits"
    }
  ]
}

Cline configures identically — same OpenAI-compatible provider, same base URL, same token — so a migration from Roo Code to Cline keeps your governance exactly as-is.

The per-user config caveat (be honest about this)

One thing worth stating plainly: Roo Code’s gateway settings live in user-editable API configuration profiles, and there is no documented admin or managed-config lockout. autoImportSettingsPath can seed a shared profile, but it doesn’t enforce one. MCP server settings are likewise per-user.

That sounds like a gap, but it points to the right mental model: you don’t govern a coding agent by locking the IDE — you govern it at the gateway. Whatever a developer types into their settings, their calls still hit your gateway, where budgets, the model allowlist, guardrails, and audit apply unconditionally. Client config is convenience; the gateway is control. Build your policy there and the per-user settings stop mattering.

A worked example: a 50-developer fleet

A 50-engineer org rolls out an AI coding agent. Without a gateway, each developer holds a provider key, picks their own model, and generates uncapped spend. Finance sees one large provider invoice with no breakdown; security has no record of what code left the building.

Route all 50 through the gateway and the picture inverts:

• Spend shows up per developer and per team, so the $9,000 monthly bill is attributable — and the three developers driving 40% of it are visible.
• A budget caps each team, so one runaway agent loop can’t blow the quarter’s quota.
• A model allowlist keeps everyone on approved, cost-appropriate models.
• Guardrails catch the .env file before it reaches a provider.
• The audit log answers “what source code touched which model” in a security review.

None of that required locking a single IDE. It required one control point.

Gotchas worth knowing

• Roo Code is end-of-life. For new rollouts, use Cline; the gateway setup is the same.
• Use the OpenAI-compatible provider, and make sure your base URL stops where the agent expects — it appends /chat/completions itself.
• The model must support tool calling for agent work; pick an allowlisted model that does.
• Model IDs must match exactly what the gateway playground shows, or you’ll hit “model not found.”
• Don’t chase client-side lockdown. Enforce budgets, allowlists, and guardrails at the gateway.

Related reading

• Claude Code governance with the AI Gateway
• Claude Code governance: building an enterprise usage policy from scratch
• OpenAI Codex governance
• Best AI gateway for Claude Code
• LLM cost attribution and team budgets
• Rate limiting AI agents: preventing LLM API exhaustion

Conclusion

The coding agent in your developers’ editors is one of the most powerful — and least governed — LLM clients you run. Roo Code’s shutdown is a good moment to fix that: whether you’re keeping existing installs alive or moving to Cline, the answer isn’t to lock down the IDE, it’s to route every call through a gateway that enforces cost, policy, guardrails, and audit on its own terms.

Point the agent at the TrueFoundry AI Gateway and the ungoverned client becomes a governed one — one key, one view of spend, one place where your rules actually hold.

Govern every developer’s coding agent

Book a demo